> Richard Zidlicky wrote:
> >
> > this is correct and a few distributions (eg m68k) rely on that
> > behaviour for installation or repair ramdisks.
>
> Then it's easy enough for them to duplicate this kernel check in userland
> at the top of /linuxrc:
compatibility wise this would not be without major pain or a compatibility
switch. It would be nasty if my users found the 4 months old installation/rescue
ramdisk suddenly broken.
> I have NO such luxury of a simple solution like that, with the decision set in
> stone in the kernel.
can you explain in more detail what makes solutions like 'init=/linuxrc' so
impractical for you?
> > If you specify 'root=xxx' than xxx is real root that is supposed to have
> > a real init and all that stuff. If that happens to be your initial ramdisk
> > than there is no need to run linuxrc.
>
> Thank you for deciding that for me.
wasn't my idea to define it that way, but I found it logical. /dev/ram should
not have more special magic than necessary, if there is need for a pre-init
phase it should be usable independent of devices.
> > Why would you specify 'root=/dev/ram' if you want linuxrc to change it
> > anyway? Either don't use 'root=' or set it to the value its supposed to
> > have after linuxrc exits which won't be /dev/ram in normal circumstances.
>
> The idea is /dev/ram0 is not a usable root. It may not even have init.
> /linuxrc provides a userland means to perform actions before init.
> This is the typical mode of opertion of thin clients, thin servers, or other
> embedded devices.
do you need some sort of preinit= kernel parameter or what? Make a patch for that,
without breaking initial ramdisks
Bye
Richard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:15 EST