Re: [RFC] Splitting kernel headers and deprecating __KERNEL__

[David Howells]

> But in general, I do kind of like the explicit marking. The same way we 
> explicitly mark the functions inside the kernel that we expose to modules, 
> we could try to mark the data structures and values that we expose to user 
> space. That tends to "work".

That gets trickier when it comes to #defines, I think.

Do you really object that much to splitting the header files as I proposed?
This should obviate the requirement for such marking (because it's implicit in
the location). Getting rid of the #ifdefs would also make the "Thou shalt not
use #ifdef" camp happier.

Doing this really shouldn't break the syscall API/ABI at all; barring of
course the potential change of location within /usr/include/ of the installed
headers, but that is simple to address. All this does is to separate out the
userspace available structures and constants.

I can grant that you might not want to use stdint types because not all the
toolchains that might be used on the kernel support them, but that's not a
reason to throw out the whole proposal.

Personally, I'd prefer us to move to using standard C99 types in lieu of u32
and co at least for the interface to userspace because they are just that:
standard.

However, I can see that there may be objections due to the fact that types may
become different logical sizes, and thus cause warnings in printf-format
string checking and pointer casting.

Also, the comparison you made to modules isn't exactly valid. We annotate
variables and functions that modules are allowed to access, but we never
export these to userspace directly; and we don't annotate structures, inline
functions, constants and macros into which categories the user-visible stuff
falls for use by modules.

David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/