RFC: enhancing the root mount logic

[Bakul Shah]

On Tue, 24 Aug 2010 07:56:08 PDT Marcel Moolenaar <xcllnt at mac.com>  wrote:
> 
> On Aug 23, 2010, at 9:33 PM, Bakul Shah wrote:
> 
> > On Mon, 23 Aug 2010 18:24:07 PDT Marcel Moolenaar <xcllnt at mac.com>  wrote:
> >> 
> >> On Aug 23, 2010, at 5:23 PM, Bakul Shah wrote:
> >> 
> >>>> The 2 reasons for doing this in the kernel are:
> >>>> 1.  resiliency against ABI changes.
> >>>> 2.  allowing /sbin/init to come from the actual root file system.
> >>>> 
> >>>> Both points are impossible to handle efficiently or correctly if
> >>>> you need user space support in getting to your actual root file
> >>>> system. You basically have a catch-22 or bootstrap problem, which
> >>>> a pure in-kernel solution doesn't have.
> >>> 
> >>> How about just bundling a small compressed ramfs with the
> >>> kernel.  The kernel unpacks it, uses it as the initial rootfs
> >>> and runs init from it. A forth/scheme/lua based program
> >>> wouldn't add more than a % or so (given that the GENERIC
> >>> kernel is over 10MB now!).
> > 
> > BTW, a friend tells me this is what Linux does (or more
> > likely, what they used in their server startup).
> 
> I see your point and buy into the argument, but not
> entirely. I explicitly mentioned "embedding" and so
> far your arguments include things like GENERIC being
> 10MB or Linux server startup.
> 
> We're not exactly discussing the same thing are we?

This friend's company used linux in an embedded system [it
was a fileserver product.  Presumably the OS had to run in a
restricted environment since the FS space would be for their
customers' use + you don't want to have to reload the OS when
a disk dies! And yet you want the ability to upgrade your OS
s/w etc.]

In my job[-2] we used FreeBSD as an embedded OS. IIRC we just
ran from a readonly flash FS as root.  An upgrade was just a
new FS image, including kernel + utilities.  Didn't Juniper
do something similar?

> I'm perfectly happy to say that the ramdisk approach
> is the most generic and solution for desktop and
> server machines but I'm not at all ready to have it
> include embedded systems just yet. It's just too
> heavy weight...

I would argue that while each individual embedded system
typically runs in a simpler environment than GENERIC, the sum
total of such embedded environments presents a large set of
alternatives. Now if you can distill all that down to a small
set of kernel changes, that is great!

But I am not doing the work, you are. So feel free to
use/ignore my input however you wish!