On 19/11/13(Tue) 15:25, Mike Belopuhov wrote: > Apparently, this leads to some funny results. There are a bunch of > prototypes under "ifndef _KERNEL": > > #ifndef _KERNEL > __BEGIN_DECLS > unsigned int if_nametoindex(const char *); > char *if_indextoname(unsigned int, char *); > struct if_nameindex *if_nameindex(void); > void if_freenameindex(struct if_nameindex *); > __END_DECLS > #endif > > That, when hidden by the netstat (it does #define _KERNEL) produces > undefined symbols at linkage time: > > % nm ./obj/netstat | grep if_indextoname > U if_indextoname > > Which results in all kinds of crashes :( > > I can't think of any way to resolve it other than including if.h > twice: once with _KERNEL, once without. But that's going to be a > huge overkill for ports.
Indeed, here's what guenther@ told me some months ago when I tried to do something similar: On 04/08/13(Sun) 00:53, Philip Guenther wrote: > Hmm. While I fully agree with hiding declarations for kernel functions > and variable behind #ifdef _KERNEL, I'm not completely convinced for types > (including structs) and #defines, particularly when they may be useful > from programs analyzing crash dumps, or even at runtime using kvm_read(). > > #defining _KERNEL in userspace programs is a horrible and incredibly > fragile workaround, as header dependencies mean these create ordering > dependencies. Adding or removing a #include from a kernel header can > break userspace programs as the headers seen with or without _KERNEL > change. Need the _KERNEL _and_ !_KERNEL parts of a header? Haha, > you're screwed! > > Is there a better way to handle this? What do people think of the > apparent convention of having a FOOvar.h header for internal stuff while > FOO.h has everything that normal (non-kernel probing) programs need? > I.e., instead of having to #define _KERNEL, a program that needs kernel > internal structure definitions would pull in the FOOvar.h file. Is that > better?
