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

Troy Benjegerdes hozer@hozed.org
Wed, 23 Mar 2005 09:11:14 -0600


On Mon, Mar 21, 2005 at 05:57:48PM -0500, Jeffrey Hutzelman wrote:
> 
> 
> On Sunday, March 20, 2005 09:34:53 AM -0600 Troy Benjegerdes 
> <hozer@hozed.org> wrote:
> 
> >>> 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..
> 
> ... is nonsensical.  You can't compare the size of a module with the size 
> of a user-mode process; that's like trying to add apples and lawnmowers.
>
> The 160k of afsd is demand-paged text, and so is "whatever glibc dragged 
> in".  It doesn't occupy any swap, EVER, and doesn't even occupy RAM unless 
> it's actually running (or ran recently and hasn't been paged out) - which, 
> for afsd, is very rarely once startup is complete.

Something changed between the linux 2.4 and the linux 2.6 implementation
then. On 2.4 (and OSX), there is a 'afsd' process running reported by
ps, and I can see what the command line arguments were.

On 2.6, all I get is:

root      2642  0.0  0.0      0     0 ?        S    Mar17   0:13 [afsd]

So where is the memory afsd is using accounted for? Is *everything* in
the kernel libafs, and afsd.c only does setup?

> Yes, libafs is pretty big.  AFS has a fairly large feature set, and that 
> one module contains the complete client implementation, including 
> components that for NFS are split across several modules.  Really, it's not 
> that out of line when you compare it to the combined size of nfs, lockd, 
> and sunrpc, and bear in mind the components that NFS does not have, like 
> cache management.
> 
> 
> FWIW, libafs is _not_ the largest module on my system.  That honor goes to 
> the nvidia driver, which weighs in at just over 4MB.

But if you are debugging something overwriting kernel memory, the first
thing you are going to do is unload the nvidia driver. The nvidia driver
also contains code for a whole bunch of different nvidia chips you're
not running.

The issue I have with libafs being so big is that it is not at all
modular. There is no opportunity for something like rxgkad to be used by
another kernel client, without also including all the other flavors of
RX. Or, for that matter, having the ability to not load rx methods that
aren't in use.

Wouldn't it be nice if there was a librxgkad that was dual-licensed
GPL/BSD and became the rxgkad implementation in the linux kernel? Then
it would provide a real alternative to rpsec_gss. Yes, this would
require some work to separate these things, but would reduce maintenance
effort over the long term.