Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 15 Dec 1998 04:31:37 -0800
From:      Mike Smith <mike@smith.net.au>
To:        NAKAGAWA Yoshihisa <y-nakaga@nwsl.mesh.ad.jp>
Cc:        Mike Smith <mike@smith.net.au>, Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, Nate Williams <nate@mt.sri.com>, Nathan Dorfman <nathan@rtfm.net>, current@FreeBSD.ORG
Subject:   Re: PAO Integration? 
Message-ID:  <199812151231.EAA05213@dingo.cdrom.com>
In-Reply-To: Your message of "Tue, 15 Dec 1998 17:22:35 %2B0900." <199812150822.RAA02605@chandra.eatell.msr.prug.or.jp> 

next in thread | previous in thread | raw e-mail | index | archive | help
> >  - We aren't CopycatBSD; the "new bus" group is attempting to develop
> >    a new, better approach to handling the bus/bridge/device 
> >    relationships.  "newconfig" is better than what we have right now, 
> >    but it is not good enough.
> 
> Why do you make another framework ? Why not improve 4.4BSD bus and
> config code ?

Because it is based on some fundamentally flawed principles, and what 
is required is a revolutionary rather than evolutionary change.

> FreeBSD, it is 4.4BSD based OS. If you want to make new
> framework, why FreeBSD ?

You could apply the same argument against changing the VM subsystem, or 
migrating to CAM, or for that matter porting from the VAX to anything 
else.

FreeBSD isn't about preserving the 4.4BSD heritage, it's about the
ongoing development of a world-class operating system taking advantage
of the foundation that we currently have.  As the saying goes, evolve or
die.

> I think FreeBSD is one of 4.4BSD-children, and I want to use BSD
> like OS, not Linux.

You're quite welcome to pick an OS that will always feel like a BSD - 
we can't however continue to feel exactly like a BSD if we want to 
adapt to the changing circumstances and our growing market.

> I want to integrate other BSDs, if possible.
> (I know, it is too hard really.)

It's impossible; if nothing else, they won't let you.

> >  - Bus architecture "incompatibility" is not actually a significant
> >    issue.  We are already 100% bus architecture incompatible with the 
> >    other BSDs, change simply for compatibility's sake won't give us any 
> >    benefits, and it would stifle any attempt to do better.  Right now 
> >    the few drivers that are shared amongst the BSD's all have different
> >    bus interface code anyway; there is nothing that will get "worse" if 
> >    we change the mechanics of the interface.  There are also things 
> >    that we are trying to do that can't be done with newconfig (at 
> >    least, as it is right now - for sure it too can be modified).
> 
> At least, I want to reduce driver porting cost. In "newconfig",
> its cost from other BSDs is quite low.

It's a fatal mistake to assume that the configuration iterface 
represents anything other than a tiny portion of the work in driver 
porting.

In many cases, it's better to reimplement the driver from scratch 
rather than try to 'port' it from another BSD - see for example the 
'de' driver for a good argument for this.

Changing just our bus code for the sake of slavish compatibility 
wouldn't actually win us much, and if you take the same argument 
further we should basically sit down and copy everything that the 
NetBSD folks do without innovating ourselves at all.

That's fairly clearly not going to work, and any partial steps in that 
direction that don't have anything else to offer would be a bad idea.

> >  - Static configuration is evil.  More specifically, static 
> >    configuration is a special case of dynamic configuration.  
> >    "newconfig" does static configuration very well, but the "newconfig" 
> >    architecture is not at all suitable for dynamic configuration.
> 
> Some case, static configuration is very useful. For example, 1
> floppy router like PicoBSD, and etc ....

As Terry pointed out, you are mistaking aggregation for static 
configuration.

config(8) does two things; it builds static tables of configuration 
data, and it arranges for code aggregation into a kernel object.

There is no dispute that it is desirable to be able to manufacture an 
aggregate kernel object; it is trivial to do this with KLD modules 
already.

There are also good arguments for supporting static tables of 
configuration information; in some cases there is no other way of 
obtaining the information a driver needs to operate.  However it is 
*not* a good idea to bind this information into the kernel object, as 
it makes *changing* the information very difficult.

> And "newconfig" is not static configuration only, also dynamic
> configuration can use. 

It would be more accurate to say that you can do dynamic configuration 
despite newconfig, but you can do that with old config as well.  
Newconfig does not offer any facilities to make dynamic configuration 
easier.

> We are planning add UserConfig to
> "newconfig", it is *true* dynamic configuration.

Userconfig is the best solution for a statically-configured kernel.  
It's not a good solution for a dynamic kernel.

> On "new-bus", How to handle boot device like console, fd, wd, ... ?

I can't make sense of this question; could you expand a little?

-- 
\\  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?199812151231.EAA05213>