Date: Mon, 12 Oct 1998 12:36:25 -0700 From: Mike Smith <mike@smith.net.au> To: "Kenneth D. Merry" <ken@plutotech.com> 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 Message-ID: <199810121936.MAA07717@dingo.cdrom.com> In-Reply-To: Your message of "Mon, 12 Oct 1998 13:24:53 MDT." <199810121924.NAA26149@panzer.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810121936.MAA07717>