[klibc] Rationale for hashed .so?

[Aaron Griffin]

On 4/7/06, H. Peter Anvin <hpa at zytor.com> wrote:
> Aaron Griffin wrote:
> > I'm curious, and perhaps a bit naive about this stuff.  I'd like to
> > know the reason for having a klibc-$HASH.so version which the shared
> > apps are linked against.  It makes it less simple to build a static
> > initramfs file list to use.
> > Currently, one has to read the libc.so.hash file to build the
> > filename, something that can't be done in a file list passed to
> > gen_init_cpio unless it's done in some sort of script.
> >
> > Could you explain the reason for this?  Is it possible to get rid of
> > this hash to make it easier to work with?
>
> The reason for this is to make sure the hash matches the klibc that a
> binary was built with, and, if necessary, to allow more than one of them
> to co-exist.
>
> The right way to fix that is almost certainly to allow gen_hash_cpio to
> accept wildcards; there are some other very good reasons to do so.

Absolutely.  I've thought of a few other things that would be nice in
gen_init_cpio: implicit directory additions (as far as I can tell,
adding /foo/bar/baz does nothing unless /foo and /foo/bar were
explicitly added - I may be mistaken though), and a 'recursive' option
- i.e. "ad *.ko from kernel/fs recursively".