From owner-cvs-all  Mon Oct 12 13:01:56 1998
Return-Path: <owner-cvs-all@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id NAA28273
          for cvs-all-outgoing; Mon, 12 Oct 1998 13:01:56 -0700 (PDT)
          (envelope-from owner-cvs-all@FreeBSD.ORG)
Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA28260;
          Mon, 12 Oct 1998 13:01:49 -0700 (PDT)
          (envelope-from ken@panzer.plutotech.com)
Received: (from ken@localhost)
          by panzer.plutotech.com (8.9.1/8.8.5) id OAA26409;
          Mon, 12 Oct 1998 14:01:26 -0600 (MDT)
From: "Kenneth D. Merry" <ken@plutotech.com>
Message-Id: <199810122001.OAA26409@panzer.plutotech.com>
Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c
In-Reply-To: <199810121936.MAA07717@dingo.cdrom.com> from Mike Smith at "Oct 12, 98 12:36:25 pm"
To: mike@smith.net.au (Mike Smith)
Date: Mon, 12 Oct 1998 14:01:26 -0600 (MDT)
Cc: mjacob@feral.com, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL28s (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk

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