On Wed, Jul 02, 2008 at 10:51:02PM +0200, Matthias Drochner wrote: > > cube%cubidou.net@localhost said: > > config(1). I'm hopeful, it will get through one day :-) > > Ah yes - but if you ask me, for a program in plain user's > PATH this is quite a namespace pollution. Should have been > renamed when it was moved. > > > I don't think there should be a compile-time decision about whether or > > not the embedded ramdisk should be used or not. > > So let's agree that if there is an embedded ramdisk it should > be initialized and made available. Whether it is used as root > device, there must be an additional hint. At that point, > "MEMORY_DISK_IS_ROOT" and "root on md0a" are about the same. Fully agreed. A simpler option could be to make md_attach look at rootdev, then (it's a dev_t, so you can make sure both the major and the minor are correct). To be honest, the thing that bugs me in your patch is that the root ramdisk still has to be md0. > > Why not getting rid of md_attach_hook and use the configured ram disk > > for the first read of an unconfigured md(4)? > > It would be much cleaner if we wouldn't instantiate a fixed > number of md(4) devices in the pseudo-device attach function, > but make it dynamic, like eg vnd(4). Yes, but it's a slightly different issue. > I'm a bit wary here because md seems to be used by embedded > ports in more creative ways. I'm with you there; maybe someone can enlighten us about those creative ways. -- 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.
Attachment:
pgpVMK_IfHM8i.pgp
Description: PGP signature