Date: Wed, 26 Mar 1997 15:38:00 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: terry@lambert.org Cc: terry@lambert.org, cjs@portal.ca, sommerfeld@orchard.east-arlington.ma.us, perry@piermont.com, hackers@freebsd.org, port-i386@netbsd.org Subject: Re: how to name fs specific programs Message-ID: <199703262238.PAA28944@phaeton.artisoft.com> In-Reply-To: <199703262154.NAA19763@Pescadero.DSG.Stanford.EDU> from "Jonathan Stone" at Mar 26, 97 01:54:12 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Johnathan Stone's address removed by request. That doesn't mean that I'm not going to respond to his posting that accompanied the request, since he made it in a public forum. I do not let "parting shots" slide. > >It doesn't make a lot of difference, unless you decide to replace the > >agregation (generic) "mount" command with an FS specific "mount" command > >at boot time. > > I honestly still dont see why I'd ever want to do such a thing.... The point is to enable people who *do* "want to do such a thing"; if you don't, then your opinion on the matter is not requested, only your opinion on implementation details (assuming you are a competent coder). > For the systems I contemplate replacing, I can drop in a NetBSD kernel > with a linked-in kernel module which implements the replaced OS's > native filesystem. NetBSD already has an emul system that lets it run > the native OS's ``agregator'' [sic] and FS-specific mount utility. What are the benefits to running NetBSD instead of the native kernel, if all the NetBSD kernel does is replace the native kernel without any additional added value? What's the point, is it just so you can say "hey, I'm running NetBSD"? > How much of your ``we have'', ``we can'', and ``posit'' is actually > real code, and how much is viewgraph engineering? It sounds rather > complicated. It seems a fair question to ask what the overhead is to > make all this work. I have a working set of agregators. I don't yet have a segment attributed kernel, thought it should be possible to do something similar to the "/fs/..." with the existing BSD install FS, which is MFS based. If we want proof of concept, USL and Sun have had this for four years. > It smells to me like you're really foisting off so much work onto the > bootblocks that deal with this `kernel as an FS' model, that we might > as well start calling the *bootblocks* the kernel, and the rest of > your ``kernel'' is just a library of OS modules. I think that is going > to set off many peoples' bogosity meters for the whole idea. This is not true. The bootblocks are to get a minimal kernel in; the issue in question is that what constitutes a minimal kernel varies based on what devices are or aren't "boot critical" devices. This dovetails nicely into using VM86() in i386 to implement fallback drivers that can work on any hardware installed on the machine. For Mac's this means ROM calls, for PPC's, this means PPCBug or Open Firmware, for non-PPC Motorola systems, this means Bug calls, for Sun's this means monitor calls, etc.. You load the hardware specific drivers after you are up, including auxillary FS drivers. But this is not required to make the concepts useful in the first place. I also admit that the concepts are only useful in terms of blocking the fewest avenues of future expansion and exploration... which was, after all, the intent. > Would you mind taking my address off any further replies, please? Done. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703262238.PAA28944>