Date: Tue, 15 Dec 1998 08:42:13 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: y-nakaga@nwsl.mesh.ad.jp (NAKAGAWA Yoshihisa) Cc: mike@smith.net.au, wollman@khavrinen.lcs.mit.edu, nate@mt.sri.com, nathan@rtfm.net, current@FreeBSD.ORG Subject: Re: PAO Integration? Message-ID: <199812150842.BAA17883@usr06.primenet.com> In-Reply-To: <199812150822.RAA02605@chandra.eatell.msr.prug.or.jp> from "NAKAGAWA Yoshihisa" at Dec 15, 98 05:22:35 pm
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 ? FreeBSD, it is 4.4BSD based OS. If you want to make new > framework, why FreeBSD ? > > I think FreeBSD is one of 4.4BSD-children, and I want to use BSD > like OS, not Linux. I want to integrate other BSDs, if possible. > (I know, it is too hard really.) > > "newconfig aproach" is improvement NetBSD-current bus and config code. I think the main reason for this is that "config" is a crutch used by kernels that can't dynamically change driver data and/or drivers. Try to name one ting that you could do with "config" that you could not do with a sufficiently dynamic kernel loadable module framework. The current three stage boot code is capable of loading a kernel and as many kld's as you need it to, at boot time. It's also capable (with a bit of hacking) of throwing away kld's for which there are no devices to attach. > At least, I want to reduce driver porting cost. In "newconfig", > its cost from other BSDs is quite low. That's a valid point of view. But so is the idea that a BSD could give ELF format kld's to a vendor for distribution on the vendor CDROM/floppies, and have FreeBSD supported automatically. The vendor wins because the BSD people did the developement, and BSD wins because the drivers and the hardware are bundled. > Some case, static configuration is very useful. For example, 1 > floppy router like PicoBSD, and etc .... That's mere agregation, to my mind, not static configuration. If you want to define an agregate as state merely because it's a fixed instance of an image, I think you are doing a disservice to the idea. > And "newconfig" is not static configuration only, also dynamic > configuration can use. We are planning add UserConfig to > "newconfig", it is *true* dynamic configuration. UserConfig is not dynamic, it's boot time. Dynamic is when you can boot FreeBSD on hardware using VM86() INT 13 calls, load a protected mode driver, and switch over to using it without rebooting. Windows 95/98 can do this because it has to to allow TSR's to operate, but no other OS comes close, not even NT. Try to install NT on a system with an unsupported SCSI controller with only a vendor supplied driver. You can do it, but there is a secret step in the middle where you have to manually copy the driver to exactly the right location on the hard drive. > On "new-bus", How to handle boot device like console, fd, wd, ... ? Generic fallback drivers, with hardware specific implemetnations that get loaded once you've bootstrapped yourself. > > I don't mean to say "newconfig is bad", so much as to say "new bus is > > better again". > > OK, But I think "newconfig is better". Better than the status quo, but not better than something that does away with the user having to mess around with interrupts altogether. Any time you can limit the exposure of the internals to the end user is a win. You understand the idea of abstracting API's? It's the same thing -- except what you are abstracting is complexity. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199812150842.BAA17883>