From owner-freebsd-current Tue Dec 15 03:35:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA15746 for freebsd-current-outgoing; Tue, 15 Dec 1998 03:35:45 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from nomad.dataplex.net (nomad.dataplex.net [208.2.87.8]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA15741 for ; Tue, 15 Dec 1998 03:35:43 -0800 (PST) (envelope-from rkw@nomad.dataplex.net) Received: from localhost (rkw@localhost) by nomad.dataplex.net (8.9.1/8.9.1) with ESMTP id FAA07262; Tue, 15 Dec 1998 05:34:32 -0600 (CST) (envelope-from rkw@nomad.dataplex.net) Date: Tue, 15 Dec 1998 05:34:32 -0600 (CST) From: Richard Wackerbarth To: Mike Smith cc: Kenjiro Cho , NAKAGAWA Yoshihisa , current@FreeBSD.ORG Subject: Re: PAO Integration? In-Reply-To: <199812132016.MAA00365@dingo.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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.") 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message