Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 12 Dec 1998 22:25:33 +0900
From:      Kenjiro Cho <kjc@csl.sony.co.jp>
To:        Mike Smith <mike@smith.net.au>
Cc:        NAKAGAWA Yoshihisa <y-nakaga@nwsl.mesh.ad.jp>, current@FreeBSD.ORG
Subject:   Re: PAO Integration? 
Message-ID:  <199812121325.WAA08728@hotaka.csl.sony.co.jp>
In-Reply-To: Your message of "Fri, 11 Dec 1998 00:56:06 PST." <199812110856.AAA00831@dingo.cdrom.com> 

next in thread | previous in thread | raw e-mail | index | archive | help

Mike Smith <mike@smith.net.au> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812121325.WAA08728>