Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 12 Oct 1998 14:01:26 -0600 (MDT)
From:      "Kenneth D. Merry" <ken@plutotech.com>
To:        mike@smith.net.au (Mike Smith)
Cc:        mjacob@feral.com, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG
Subject:   Re: cvs commit: src/sys/cam/scsi scsi_da.c
Message-ID:  <199810122001.OAA26409@panzer.plutotech.com>
In-Reply-To: <199810121936.MAA07717@dingo.cdrom.com> from Mike Smith at "Oct 12, 98 12:36:25 pm"

next in thread | previous in thread | raw e-mail | index | archive | help
Mike Smith wrote...
> > This won't happen before 3.0.
> 
> I had no delusions about this. 8)

Good.  :)

> > > 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.

Well, the main problem would be how to get the quirk entries off the disk
without a disk driver?  I guess the answer is by using the BIOS driver or
something like that, but I have no idea how that would work.

> 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.

It would be more important if we were a commercial, binary-only operating
system.  Since folks have the source and can easily add their own quirks
and recompile, it's less of a priority. :)

Ken
-- 
Kenneth Merry
ken@plutotech.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?199810122001.OAA26409>