Date: Mon, 28 Sep 1998 23:47:55 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: reg@shale.csir.co.za (Jeremy Lea) Cc: tlambert@primenet.com, phk@critter.freebsd.dk, gibbs@narnia.plutotech.com, current@FreeBSD.ORG Subject: Re: Current is Really Broken(tm) Message-ID: <199809282347.QAA13327@usr04.primenet.com> In-Reply-To: <19980928161951.B286@shale.csir.co.za> from "Jeremy Lea" at Sep 28, 98 04:19:51 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> I want to display my complete ignorance and cluelessness (especially with > all things related to kernels and devices and booting), by asking a silly > question. It's sort of related to this thread but sort of not... well at > least I think so. > > On Sun, Sep 27, 1998 at 08:59:02PM +0000, Terry Lambert wrote: > > Which the kernel has to know anyway, in order to mount things. > > The structures are there, and they're not going to go away, no > > matter how ugly their being there is deemed. Well, until we > > support discardable ELF section tags for unused kernel components. > > Why doesn't the kernel always use an MFS as root? I've seen a ton of traffic > go by on these lists about the magic needed to mount root partitions, and it > would seem to me (in my small mind), that using an MFS, like the boot > floppies and PicoBSD, which would always be a `known' quantity, would make a > lot of these problems go away. Ideally, you would use a union mount, and mount the root partition on top of a: / | +- /dev | +- /proc Which would incidently address the /dev persistence camp's objections to progress which orphans shell scripts from 1978. But the VFS layering is broken, and no one will commit fixes that offend their idea of The Right Way To Do Things, yet they don't write code implementing The Right Way To Do Things themselves, so it remains broken, and this won't work. > Maybe it would have to be a special kind of MFS, rootfs, which worked a bit > differently to a normally MFS. Maybe it should only be able to hold mount > points. The FS code doesn't actually need a mount point to cover to allow mounts, so this is an unnecessary task. > Maybe it could be a memory image loaded directly by the boot blocks, > which contained the kernel (and maybe lkm's?). Maybe the image could be > stored on a DOS (e.g.) partition/slice? Maybe the image could then be used > as backing store if the MFS needed it? This is a bad idea with the existing MFS code. The existing MFS code is not so much an MFS as it is an FFS on a pretend memory device. The upshot of this is that once memory is taken, it can't readily be given back to the system. In terms of including LKM's in the kernel image, the easiest thing to do in an ELF world is to merely archive the LKM's as seperate ELF sections into the kernel. In actuality, we really ought to agregate all device drivers into the kernel image this way, and make no distinction between objects that are archived together, vs. LKM's. To do this, the concept of a linker set has to change to agregate linker sets from several ELF sections into a single set. Then you load the monolithic kernel, paging things in as necessary in order to run the probes, and discard all the pieces you aren't going to actually use to shrink the kernel's memory footprint. So it's really not necessary to do an MFS implementation to get everything needed available to the kernel, though it would be a nice project for someone to write a more dynamic MFS. > Don't laugh, I really don't understand most of this. Don't even understand > most of the terms. I just don't like having questions running around in my > head... >From the correct use of terms, I suspect you are better educated than you suspect you are. 8-). 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?199809282347.QAA13327>