lkml.org 
[lkml]   [2009]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: FatELF patches...

> > think if Ubuntu did this as a distribution-wide policy, then people would
> > probably choose a different distribution.
>
> Hmm.. so let's see - people compiling stuff for themselves won't use this
> feature. And if a distro uses it, users would probably go to a different
> distro.

I probably wasn't clear when I said "distribution-wide policy" followed by
a "then again." I meant there would be backlash if the distribution glued
the whole system together, instead of just binaries that made sense to do
it to.

And, again, there's a third use-case besides compiling your programs and
getting them from the package manager, and FatELF is meant to address
that.

> Actually, they can't nuke the /lib{32,64} directories unless *all* binaries
> are using FatELF - as long as there's any binaries doing things The Old Way,
> you need to keep the supporting binaries around.

Binaries don't refer directly to /libXX, they count on ld.so to tapdance
on their behalf. My virtual machine example left the dirs there as
symlinks to /lib, but they could probably just go away directly.

> Don't forget you take that hit once for each shared library involved. Plus

That happens in user space in ld.so, so it's not a kernel problem in any
case, but still...we're talking about, what? Twenty more branch
instructions per-process?

> I'm not sure if there's hidden gotchas lurking in there (is there code that
> assumes that if executable code is mmap'ed, it's only done so in one arch?

The current code sets up file mappings based on the offset of the desired
ELF binary.

> Or will a FatELF glibc.so screw up somebody's refcounts if it's mapped
> in both 32 and 64 bit modes?

Whose refcounts would this screw up? If there's a possible bug, I'd like
to make sure it gets resolved, of course.

--ryan.



\
 
 \ /
  Last update: 2009-11-02 16:17    [W:0.076 / U:1.620 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site