On Wed, Jul 02, 2008 at 09:39:51PM +0200, Matthias Drochner wrote: > > Since md(4) is a first-class device now, it should be > possible to remove more of the special hacks to make > it the root device. After all, there is the "root on" > config(8) directive which should control this. config(1). I'm hopeful, it will get through one day :-) > The "root on" doesn't issue cpp definitions afaict, > so one couldn't do compile-time decisions based on the > root-nedd of md. > For me, this looks OK, but I've only tested an INSTALL > kernel, with the appended patch. There are likely > other uses; in particular I didn't try to load a ramdisk > as module yet. I don't see why it shouldn't work. > Comments? I don't think this gives us anything save for one less line in the INSTALL kernel config; a line unlikely to be touched anyway. I don't think there should be a compile-time decision about whether or not the embedded ramdisk should be used or not. Why not getting rid of md_attach_hook and use the configured ram disk for the first read of an unconfigured md(4)? Doing it in mdopen might be an issue if you want to configure a new md and leave the ramdisk data untouched. So it might be read or getdisklabel or something, so that it happens when the root file-system is being searched. The advantage of that is that you can embed a root file-system in your kernel but only boot it when you do "boot md0a:netbsd" at the boot prompt. It also leaves the door open to having a ramdisk containing modules and the like (granted, all of this lacks a facility to free the ramdisk if needed). -- Quentin Garnier - cube%cubidou.net@localhost - cube%NetBSD.org@localhost "See the look on my face from staying too long in one place [...] every time the morning breaks I know I'm closer to falling" KT Tunstall, Saving My Face, Drastic Fantastic, 2007.
Description: PGP signature