From owner-freebsd-current Tue Dec 15 04:07:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA20653 for freebsd-current-outgoing; Tue, 15 Dec 1998 04:07:41 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dingo.cdrom.com (goldfish.pht.co.jp [210.171.55.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA20644 for ; Tue, 15 Dec 1998 04:07:39 -0800 (PST) (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 EAA05066; Tue, 15 Dec 1998 04:05:06 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199812151205.EAA05066@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Richard Wackerbarth cc: Mike Smith , Kenjiro Cho , NAKAGAWA Yoshihisa , current@FreeBSD.ORG Subject: Re: PAO Integration? In-reply-to: Your message of "Tue, 15 Dec 1998 05:34:32 CST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 15 Dec 1998 04:05:06 -0800 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > On Sun, 13 Dec 1998, Mike Smith wrote: > > > It's worth pointing out that we are now quite a long way down the path > > to this goal; by no means all the way there, but the new bus > > architecture coupled with KLD modules does largely obviate the need for > > config(8) in the first place. > > > > I'm of the strong opinion that our current direction, taking us away > > from static configuration, is the right one to be taking in the context > > of our current and projected future target architectures. It is no > > longer adequate nor desirable to require the kernel to be rebuilt to > > adapt to a new system configuration, and we need to reflect this in our > > architecture. > > I support Mike's opinion on this matter. At the same time, I think that > the PAO folks recognize that there is a need to support the rogue devices > that cannot be handled in any fashion other than manual intervention > ("Damn it! I know that this card uses IRQ .. and .... . Just do it that > way.") There's no way that we're going to obsolete "manual configuration" in the forseeable future; ISA is not going to die that easily I fear. > Can we have a scheme whereby the "ultra-new-config" utility generates > glue modules for just those devices? By adding the resulting KLDs to the > load mix, the legacy hardware would be accomodated in the same framework > that the rest of the dynamic system uses. The problem that we're seeing in this discussion is the confusion between configuration information and driver code, or the module and its metadata. There will always be a mechanism for passing metadata to an instance of a driver. -- \\ 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 freebsd-current" in the body of the message