[OpenAFS-devel] Refactoring the Solaris libafs code base

[Sean O'Malley]

On Sat, 30 Dec 2006, Marcus Watts wrote:

> Kernel side building is not nearly as standardized; there is no
> completely portable way to handle includes.  Since the kernel isn't
> (usually) linked against libc, many functions that are present in
> userland code aren't present inside the kernel, so files such as
> stdio.h simply don't make sense there.

Excuse my ignorance

The libc argument to me would make a lot more sense if the kernel module
was a shared object or used shared libraries. But since they are
static, and don't include shared libs the symbols should already be
included at linking which gives credence to Mr Allbury's suggestion of
just dropping the guards altogether.

The netutils.c argument Mr. Altman gave would make a lot more sense if
afsd was actually a kernel module, since it just interfaces with the
kernel module and already dynamically linked against libc.., it doenst
make quite as much sense to me. But if I am wrong...

netutils.c  does have:
#include <stdio.h>
#ifdef HAVE_STRING_H
#include <string.h>
#endif
#ifdef KERNEL
(paraphased)

Which isn't consistant with not including userland symbols in kernel code.

Since the kernel modules are statically linked, I could drop the guards as
Mr Allbury suggested to clean up the code and thusly I submitted a patch
that did just that.

Given what you said for consistancy sake... I could leave the guards on
for string.h, and put guards on stdio.h, stdlib.h, etc. and then in
afs/sysincludes.h for say string.h

at the top add:
#ifdef HAVE_STRING_H
#undef HAVE_STRING_H
#endif

and in the solaris ifdef put
#include <sys/systm.h>

(which has symbols for a lot of the string functions, and I am not sure
about other platforms.. Actually the symbols in string.h are supposedly
safe for the kernel on solaris or at least that is my brief
understanding and sys/string.h on linux just includes string.h (or at
least the 2.6 kernel..)

Im not trying to be an ass, I am just trying to get some understanding
and try to get some consistancy so it isn't quite as hard of a maze to
wallow through.

Sean


--------------------------------------
  Sean O'Malley, Information Technologist
  Michigan State University
-------------------------------------