[OpenAFS] jafs et al

[Russ Allbery]

Marcus Watts <mdw@umich.edu> writes:

> I don't think there's any one best answer.  There's actually several
> dimensions here:

> 	pic vs. nonpic
> 	lwp vs. pthread
> 	user vs kernel mode vs. "user kernel" mode

> although these aren't strictly independent.  Perl has its own special
> brand of weirdness, especially in regards to threading, & tossing mit
> kerberos 5 and glibc into the mix can produce fascinating but bad
> behavior.  In some environments (many?) - linking against pthread would
> be very attractive, but not on linux.

Er, linking against pthread is very attractive to me on Linux.  What am I
missing?

> In some environments (many?) - mixing pic and non-pic code is kosher,
> but apparently not ibm big-endian iron.

Mixing PIC and non-PIC code is not kosher in general.  There just happens
to be a few interesting exceptions where you can get away with it,
including x86 Linux.  You can't mix PIC and non-PIC on amd64 Linux, let
alone weirder stuff.

> I think for openafs, it would make sense to have a "enable-pic"
> configure flag - that could turn on pic mode globally.  That could be
> used to build static libraries for pam, perl & whatever as one
> relatively clean approach, without compromising server performance.

Well, that I could do now.  But building AFS twice and then extracting
libraries from the second build is really obnoxious from a packaging
perspective, because now you also have to chase every package that depends
on AFS libraries and get them to update what libraries they're linking
with and tack _pic on to the end, or you have to have two directories of
AFS libraries, or you have to install server binaries built with different
libraries than you ship in the dev package.

It's all doable and all ugly.

The clean approach from a Linux perspective is to have a shared library
with a versioned API that you can link against.  It saves overhead,
reduces memory usage, and makes packaging far cleaner.  It's just a lot
more work getting it right and keeping it right.

But I'm going to keep banging the drum until hopefully we can find time to
do it.  :)

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>