On Mon, 16 Dec 2013 11:00:34 +0000
Laurent Bercot <[email protected]> wrote:

> 
> > You are making a very *big* assumption that the kernel can find
> >  the real root filesystem without userspace help. In cases where
> >  the kernel can't - initramfs/initmpfs is in fact very useful.
> 
>   Show me a precise, real-life example, and I'll tell you how I would
> proceed. Or agree with you.

Lauri and Didier have given you good examples - I thought their use cases (PXE 
/ NFS root) are immediately obvious as the "classic" need for initramfs. I will 
add another one - running aufs or overlayfs as root filesystem. 

> 
>   Actually, Lauri has a point: if the root filesystem has to be in RAM
> (storage-less machines) then yes, initramfs is useful - as a real
> root filesystem; you probably don't even need to switch_root, which
> simplifies things a lot.

Yes. Whether to switch_root or not, it depends on the needs, though - if one 
wants to have persistent changes saved across sessions, it's probably best to 
switch root to network-based filesystem or use some kind of overlayfs I hinted 
above to do it.

>   But as far as machines with some kind of storage go, I've seen my
> fair share of them, and I've never encountered a case where initramfs
> was the best solution. I don't claim to have seen it all, though -
> there might be use cases I'm not aware of.

In this case there are always alternative solutions. In devices with storage 
where the initial root filesystem is always accessible (e.g. in ROM) you can 
always do your initialisation straight in the real root and then pivot_root to 
do something else if need be (this effectively makes the your real root's init 
script does the work that is normally done in initramfs). Whether this is 
better than doing it in initramfs is debatable; but as I said earlier, the  
initramfs/initmpfs is indisposable if you need to use rootfs which can't be 
mounted directly by the kernel without userspace help.

-- 
James B <[email protected]>
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox

Reply via email to