Adding Steve to the CC list as I'd like his input from the
glibc/powerpc side as he's the requester of that feature in the first
place.
Steve: Roland is proposing to ues dsocaps instead of AT_BASE_PLATFORM.
Cheers,
Ben.
On Mon, 2008-07-07 at 17:31 -0700, Roland McGrath wrote:
> > > The kernel does not have to come from the same place as the root
> > > filesystem. You may want to run a new kernel with an old filesystem, or
> > > vice-versa.
>
> Well, it's not like these bits are really going to change in practice. My
> point was just that this is a far "softer" ABI than the general kernel-user
> contract. Sorry if my being precise about things gives you indigestion.
>
> > I agree, I'm pretty dubious here...
>
> Dubious about whether the dsocaps bit assignments are "part of the ABI"?
> Fine. Let's talk again when you've used up 32 bits and want to figure out
> what to do next.
>
> Dubious about whether dsocaps is the right thing to do? I think you are
> overlooking what the actual kernel-user compatibility reality is here.
>
> Firstly, what is the "risk" in the "gone wrong" case? The risk is that a
> DSO load via ld.so.cache will overlook a /lib/power99/foo.so match and get
> a /lib/foo.so match instead because ldconfig doesn't know about "power99".
> If foo.so wasn't in ld.so.cache at all, there is no problem.
> If you used LD_LIBRARY_PATH, there is no problem.
> If you used dlopen with an explicit file name (has /), there is no problem.
>
> What happens if you boot a kernel that uses dsocaps with the new string
> "power99", but you are missing the ld.so.conf.d file to match your kernel?
> Then a DSO load via ld.so.cache will overlook "power99" matches.
>
> How do you fix it?
> Install the right (tiny text) file, and run ldconfig.
>
> What happens now if you are using a new kernel that supplies a new string
> "power99" in AT_PLATFORM or another auxv element used the same way, but
> with an old root filesystem (say one including any glibc that exists today)?
> Then a DSO load via ld.so.cache will overlook "power99" matches.
>
> How do you fix it?
> You add a bit assignment in the glibc sources, recompile glibc,
> install a new whole glibc package. (Conceivably if you are extremely
> careful you can manage to redo an otherwise completely identical
> build to the glibc on your old system and replace only ld{64,}.so.1
> and ldconfig.) Then run the new ldconfig.
>
> In short, if you use a root filesystem from before kernels started using
> the new string, then you will degenerate to default-platform library
> matches from loads via ld.so.cache (i.e. /lib/foo.so, not
> /lib/somecpu/foo.so).
> If you want to do better than that for this case, it's intractable using
> AT_PLATFORM, and simple using dsocaps (probably simpler than booting a
> special kernel was).
>
> I haven't figured out what in this old-vs-new picture you think AT_PLATFORM
> or something else like it would ever buy you.
>
>
> Thanks,
> Roland
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
