[OpenAFS-devel] configure not honoring 'CC' environment variable

[Troy Benjegerdes]

> >This issue would be a lot easier to sort out if the kernel and userland
> >code were clearly separated. Or at least the build process. Is there
> >documentation or whitepapers that I can look up at what afsd actually
> >does before handing off control to libafs in the kernel? I'm wondering
> >why both afsd and libafs are so big.
> 
> You can read src/afsd/afsd.c; it's actually a fairly simple program.  I'm 
> not sure why you believe afsd is 'big'; mine is all of 168K.

libafs is by far the biggest kernel module I have loaded.. 

Module                  Size  Used by
nfsd                  258944  9
libafs                606052  2
ipv6                  282752  18
nfs                   220272  2
lockd                  70768  3 nfsd,nfs
sunrpc                162232  16 nfsd,nfs,lockd
unix                   32936  20

that plus another 160k from afsd plus whatever glibc dragged in..

> 
> >What happens if I have a 32 bit userland, and a 64 bit kernel, for
> >example. So far I've always punted and built all of afs 64 bit.
> 
> With the exception of afsd, we are rapidly approaching the point where 
> 32-bit userland tools can be expected to work on most of the 64-bit Linux 
> platforms.  As of the 1.3.80 release due out shortly, I expect this will 
> work for any process using the /proc interface (wihch is the case for 
> anything linked against a reasonably modern version of either the OpenAFS 
> libraries or KTH's libkafs), and for processes using the syscall interface 
> on those architectures where we successfully locate and patch the secondary 
> 32-bit syscall table.  You will be able to tell if this works by looking at 
> dmesg output after loading the libafs module; it print either the address 
> of the 32-bit syscall table, or a message indicating it could not be 
> located.
> 
> There is currently no guarantee that a 32-bit afsd will work with a 64-bit 
> kernel.  For this to work, the kernel code would have to translate some of 
> the data structures passed in by a 32-bit afsd, and I don't believe the 
> analysis has been done to determine which structures are affected and make 
> sure they are handled.

In this case, I'd say the build process for afsd and the kernel should
be separated from the rest of the userland tools. But then I suppose
afsd still needs all the libraries, which is a big chunk of the build.