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>