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 ------------------------------------- _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
