[klibc] symlinks and initramfs (was klibc-1.2.1: kinit works...)

[H. Peter Anvin]

Aaron Griffin wrote:
> On 1/31/06, Milton Miller <miltonm at bga.com> wrote:
> 
>>I would request we not put in symlinks.  The problem is that they are
>>difficult to override.  Loading a later cpio has the effect of
>>(attempting to) write over the current target of the symlink.  There is
>>no "remove existing file or directory" entry in cpio.  This and the
>>fact that initramfs only extends files are the two biggest limitations
>>I've run into during the past 3 plus years.
> 
> I kind of thought that was the point he was making.  /kinit exists as
> a hard file, symlinked to /init so that a user built initramfs can
> replace /init easier, while still keeping /kinit in place.  Sure, you
> could load an initramfs which overwrites /kinit while still expecting
> /init to work as normal, but at that point you're just trying to
> protect fools from themselves.
> 

No, the point he's making is that we need to make sure that the 
in-kernel cpio extractor can handle overwriting a symlink with a file, 
which I'm not sure the current one does.

	-hpa