From owner-cvs-all Mon Oct 12 18:07:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA24314 for cvs-all-outgoing; Mon, 12 Oct 1998 18:07:24 -0700 (PDT) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA24294; Mon, 12 Oct 1998 18:07:14 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id SAA01071; Mon, 12 Oct 1998 18:10:58 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199810130110.SAA01071@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 14:01:26 MDT." <199810122001.OAA26409@panzer.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 Oct 1998 18:10:57 -0700 From: Mike Smith Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk > > 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. They'd be loaded by the bootstrap; one of the features of the 3-stage bootstrap is that it can do this sort of thing. There's a simple lookup interface available within the kernel for locating stuff loaded by this. > > 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. :) Yes, although we are endeavouring to penetrate markets where rebuilding from source is less of an option (due more to the people than the situations involved nonetheless). -- \\ 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