[OpenAFS-devel] Re: [OpenAFS] jafs et al

[Jeffrey Hutzelman]

On Wednesday, March 14, 2007 12:20:20 AM -0700 Russ Allbery 
<rra@stanford.edu> wrote:

> Marcus Watts <mdw@umich.edu> writes:
>> Russ Allbery <rra@stanford.edu> writes:
>
>>> Er, linking against pthread is very attractive to me on Linux.  What am
>>> I missing?
>
>> Depending on the version of linux (& glibc) you're more or less likely
>> to get a "different process" per thread, which affects things like
>> "kill", "wait", and "ps".
>
> So it's just low-level weirdness along those lines?  That doesn't really
> bother me.  (And hm, doesn't the new threading model not expose things
> that way any more, or am I confused?)

You are not confused; it hasn't worked that way in some time, and even when 
it did, it wasn't as bad as all that.  Yes, multiple threads were 
separately visible in ps (and still are, if you use the correct switch), 
but waiting and signal delivery actually worked they way they should.


>> Also, it's not as true as all that even on amd64.  On amd64, even by
>> default, non-pic executables link dynamically against pic shared
>> libraries.  Non-pic executables can also be statically linked against
>> pic objects.  What breaks is linking non-pic code into shared libraries
>> and objects.
>
> Right, sorry.  Yes, there are cases that are even more restrictive, but
> that's the common one and the one that I'm the most concerned with, since
> it's directly relevant to both Perl modules and PAM modules.
>
>> Indeed, on most machines, non-pic code in shared libraries is frowned
>> upon, and amd64 is merely enforcing a very common policy.  It happens to
>> work with i386/gnu, and that's the real anomaly here.

I wouldn't describe this as "enforcing a policy".  It's not just a policy; 
there are technical reasons why putting non-PIC code in shared objects 
doesn't work.  Those just happen not to apply on some platforms, and I 
think we all agree that there has been much bad practice as a result of 
x86-linux being one of them.


> A solution specific to AFS is only partly helpful, and nowhere near as
> helpful as AFS starting to act like the rest of the world.

Agree.  Largely that means providing archive and shared libraries with the 
same names and ABI's, instead of requiring people to use different library 
names depending on whether they want shared or archive libraries _and_ 
conflating that distinction with lwp-vs-pthread.