From owner-freebsd-current Sat Dec 12 05:25:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA23536 for freebsd-current-outgoing; Sat, 12 Dec 1998 05:25:43 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from widefw.csl.sony.co.jp (widefw.csl.sony.co.jp [133.138.1.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA23531 for ; Sat, 12 Dec 1998 05:25:40 -0800 (PST) (envelope-from kjc@csl.sony.co.jp) Received: from hotaka.csl.sony.co.jp (root@hotaka.csl.sony.co.jp [43.27.98.57]) by widefw.csl.sony.co.jp (8.8.8/3.6W) with ESMTP id WAA04154; Sat, 12 Dec 1998 22:25:34 +0900 (JST) Received: from localhost (kjc@[127.0.0.1]) by hotaka.csl.sony.co.jp (8.8.8/3.6W/hotaka/98111120) with ESMTP id WAA08728; Sat, 12 Dec 1998 22:25:33 +0900 (JST) Message-Id: <199812121325.WAA08728@hotaka.csl.sony.co.jp> To: Mike Smith cc: NAKAGAWA Yoshihisa , current@FreeBSD.ORG Subject: Re: PAO Integration? In-reply-to: Your message of "Fri, 11 Dec 1998 00:56:06 PST." <199812110856.AAA00831@dingo.cdrom.com> Date: Sat, 12 Dec 1998 22:25:33 +0900 From: Kenjiro Cho Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Smith said: > The new-bus people talk from the view of the entire architecture, but > the focus of the PAO people is how to face the reality *NOW*. >> If that was all they were doing, that'd be ideal. The real problems >> arising at the moment however stem from the PAO team laying plans for >> long-term development without considering the directions that other >> groups are taking. This is a communication problem. I did some research on this issue in the -hackers archive. When itojun brought up "newconfig" back in June, you said you would support it if it works. Jordan encouraged them to give it a try. Then, the PAO team decided to go for "newconfig". Apperently, new-bus has evolved a lot since then and the situation has changed, but the PAO folks are unaware of the directions that other groups are taking. The following messages are found in the archive. Mike Smith said (08 Jun): > If something is already decided about this topic, please give me > some pointer for the discussion archive. I do not want to spend > my time to this, if it will never be merged into. From an entirely pragmatic perspective, "new" config is better than "old" config. It's not the solution we are looking for, but it's a step in the right direction. If the integration will be carried through to completion, then I would be inclined to offer my support (whatever that's worth 8). Then, Jordan said (08 Jun): Well, every time this comes up, a number of folks chime in with "but config(8) is fundamentally WRONG! We must get rid of it entirely, not upgrade it!" and it is my suggestion that you simply ignore all of those people and go right on ahead with this idea. The reason I suggest ignoring them has to do with the fact that it's exceedingly easy to point out the flaws in config(8) but obviously not so easy to architect a complete replacement or someone would have done so by now. Note that I'm not even talking about an implementation, I'm talking about a reasonable attempt to even _architect_ such a thing. I've seen many a pie-in-the-sky treatise go by about how things ought to work, but not much which really went into significant detail on how a migration away from config(8) should be done and a sample timeline showing which tasks will need to be done and in what order. If the NetBSD/BSDI folks have improved config(8) to the point where it's signficantly more usable, I don't see the harm in going in that direction. If the new-paradigm weenies also want to use that as a sufficient goad to get them to really implement a complete replacement, then that's pretty much a win too since nothing else seems to be motivating them these days. DG also said that he was neutral on the issue. --Kenjiro To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message