lkml.org 
[lkml]   [2001]   [Sep]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Initrd Dynamic v4.2 - New Feature: Tmpfs root support


On Sun, 23 Sep 2001, David Cinege wrote:

> Now, could you please explain to me how the hell you boot to a tmpfs
> root from userland!?!? This feature *creates* your userland.

And that's _all_ you need on the kernel side.

> Maybe you're just confused what this feature does. Maybe you've never
> worked with systems that run a volatile root. Maybe you've just never made
> a boot disk.

> Maybe you even think it's sane to compile userland into the kernel? <snicker
> snicker> I just looked at your initramfs. From what I see it's the same
> scheme I used to use In the Linux Router Project before I wrote
> initrd-archive. Except I did it *entirely* in userland back in 1997. It
> sucked. Badly.

Which somewhat contradicts the paragraph above (and common sense, while
we are at it). BTW, I would really love to hear how TF did you manage
a non-breakable chroot jail 4 years ago _and_ in userland.

> > _Please_, let's stop
> > adding complexity to already ridiculously bloated late boot stages.
>
> It's funny you've refered to my patch as bloated. What you've wrote (which is
> a limited solution) weighs in at ~122k. Initrd Dynamic is ~35K complete and

Not patch. The late-boot logics itself. BTW, while we are comparing patch
sizes, count how much is added and how much is removed.

> > David, no offence, but let's do it the right way.
>
> It is done right. Infact, I'm proud that this release finally has implemented
> it to perfection for the purposes it was designed. It took 3 years
> to get to this point of a completly dynamic, modular, ram based root.
>
> It never fails, post a patch to kernel and they come out of the wood work
> with delusional bitching. This is one reason I sat on releases for 9 months.
> BTW Offence intended...

... and failed. Frankly, it takes more than that to offend. As a flame
it's below mediocre.

As for the code... _all_ you need on the kernel side is "unpack <some_archive>
to ramfs/tmpfs and do exec()". That's it. The rest can be done in userland.
That includes the logics with loading ramdisk from initrd/floppies, handling
nfsroot, choosing final root device, yodda, yodda. And yes, I consider
ripping that logics from the kernel space a Good Thing(tm). Among other
things, it allows to replace deeply rotten code with invoking a couple of
syscalls. I have no problems with using your code as a base for that, but
that should be done. Current fs/super.c::mount_root() should go. Again,
I've no problems with keeping that in form of sys_foo() called from the
kernel space (initramfs is incremental to exactly that - see init/do_mounts.c
in namespaces-patch). But let's get all that logics into one place and
do it in clean way. Even if we rip 90% of it in 2.5 (loading ramdisk from
multiple floppies with requests to change them - b0rken on powerpc, BTW;
or the lovely way we sometimes forget to ask to eject the damn thing -
have fun with that on Sun boxen), I'd rather see it done when we have
the sucker cleanly separated from the rest of the kernel. Which is more
than 35Kb - just removing all that code from the multiple places it lives
now will take more. Grep around for wait_for_keypress() and you'll see
what I mean.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:03    [W:0.034 / U:16.260 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site