Re: FatELF patches...

From: Ryan C. Gordon
Date: Mon Nov 02 2009 - 10:14:23 EST

> > 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

> 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 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, 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 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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at