On 27.08.2010 13:59, Eric Valette wrote:
quoted text
> On 08/26/2010 09:53 PM, Phil Turmel wrote:
>
>>
>>> Now I'm really puzzled grub2 as a "search by fs uuid" command that linux is unable to deliver for the root device!
>>
>> The key word here is "unable".  The maintainers aren't *unable* to do this.  They are *unwilling* to do this.  I don't recall the precise discussion, but basically it boils down to the fact that early userspace (aka initramfs) can do this efficiently, and it needs to be supported in initramfs for other reasons, so it is pointless to duplicate this code in the kernel.  I'm sure block folk will chime in if this isn't a fair representation (my apologies in advance if so).
>>
>> Try dracut.  Seriously.  It's lean and mean just for this use-case, and you'll be protecting yourself against future changes in the block layer.  And you can put root=LABEL=foo on your kernel command line to match your fstab.
>
>
> This is a rather bizarre argument as because of this situation
> 	1) the code is duplicated between the initramfs and the real disk

I don't really get what you mean.
But binary duplication isn't the issue, source-code duplication is.
I'd count an initramfs to the binary category. It is "compiled" more or 
less literaly.

quoted text
> 	2) the initramfs has to be rebuild each time a new kernel is done

Only when you use kernel-modules, otherwise you should be fine for "some 
time".

quoted text
> 	3) The tmpdevfs is also a dupplicate somehow

No.

devtmpfs uses tmpfs or ramfs as backing-store. And it doesn't really 
duplicate udev either, as it only does the bare minimum needed to get 
the computer to the point where udev can do the rest. Like when you have 
a root filesystem with no /dev at all.
(Which was kind of an chicken & egg-problem before.)





Bis denn

-- 
Real Programmers consider "what you see is what you get" to be just as 
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated, 
cryptic, powerful, unforgiving, dangerous.

--
unsubscribe notice
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/