Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 13 Dec 1998 12:16:57 -0800
From:      Mike Smith <mike@smith.net.au>
To:        Kenjiro Cho <kjc@csl.sony.co.jp>
Cc:        Mike Smith <mike@smith.net.au>, NAKAGAWA Yoshihisa <y-nakaga@nwsl.mesh.ad.jp>, current@FreeBSD.ORG
Subject:   Re: PAO Integration? 
Message-ID:  <199812132016.MAA00365@dingo.cdrom.com>
In-Reply-To: Your message of "Sat, 12 Dec 1998 22:25:33 %2B0900." <199812121325.WAA08728@hotaka.csl.sony.co.jp> 

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".

More to the point, I said I'd support it if integration was taken to 
completion, which is a lot more than "works".  Back in June there was 
also no action from Doug on his alternative design, so I had no hope 
for it.

> 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.

This could definitely do with some help.  It's important that we don't 
become divided over what is in many ways a relatively trivial (if 
crucial) issue.

> Then, Jordan said (08 Jun):
...
>   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.

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.

-- 
\\  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



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