From owner-cvs-all Mon Oct 12 12:32:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA21267 for cvs-all-outgoing; Mon, 12 Oct 1998 12:32:26 -0700 (PDT) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from dingo.cdrom.com (castles203.castles.com [208.214.165.203]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA21154; Mon, 12 Oct 1998 12:32:01 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id MAA07717; Mon, 12 Oct 1998 12:36:26 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199810121936.MAA07717@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Kenneth D. Merry" cc: mike@smith.net.au (Mike Smith), mjacob@feral.com, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c In-reply-to: Your message of "Mon, 12 Oct 1998 13:24:53 MDT." <199810121924.NAA26149@panzer.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 Oct 1998 12:36:25 -0700 From: Mike Smith Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk > Mike Smith wrote... > > > We're going to put in a mechanism in the next day or two to allow > > > specifying SCSI revision in quirk entries. This will allow us to disable > > > cache sync, multi-lun probing and serial number inquiries for SCSI-1 > > > devices. > > > > Hmm. Would you consider adding a facility to parse a text-format quirk > > description and add it to the compiled-in tables (if unique?). > > Yes, I'll certainly think about doing it. It would probably be best to do > it via camcontrol. That would be too late. > It'll require mallocing memory in the kernel to store the additional quirk > entries, and therefore could be abused by a malicious hacker. But then > again, it would be much easier to just send a nice format unit command..:) Indeed. > Another difficulty will be handling the fact that we've got a number of > quirk tables, not one master quirk table like the old code. This will > probably require some thought/design to implement. No problem. > This won't happen before 3.0. I had no delusions about this. 8) > > If you were to do this, it would be possible to read quirk entries from > > a file during the boot phase, decoupling the quirk data from the kernel > > code. (This would eg. make it possible to boot/install on a system > > which wouldn't run without a quirk entry.) > > Hmm, how early in the boot phase? The earlier in the boot phase it goes, > the more difficult it would be to do. If you're talking about from > /etc/rc, then sure, it could be done via camcontrol or something similar. > Doing it before the CAM probe phase would be much more difficult. Why? You'd just have a set of linked lists of quirk tables, initialised by a SYSINIT very early on. This would know how to look for sources of quirk data, including the compiled-in "standard" tables, and possible extra sources. The real plus here is decoupling the quirk data from the code itself; the two don't belong together. You should, ideally, be able to add a line to a configuration file describing the quirk and have things "just work" without having to rebuild the kernel. I realise this is not likely to be a high priority for you folks, and in reality it's probably not massively important, but it's one of many small steps towards organising the kernel. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message