lkml.org 
[lkml]   [2004]   [Nov]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] Splitting kernel headers and deprecating __KERNEL__


On Mon, 29 Nov 2004, Paul Mackerras wrote:
>
> uint32_t is defined to be exactly 32 bits wide, so where's the problem
> in using it instead of __u32 in the headers that describe the
> user/kernel interface? (Ditto for uint{8,16,64}_t, of course.

Ok, this discussion has gone on for too long anyway, but let's make it
easier for everybody. The kernel uses u8/u16/u32 because:

- the kernel should not depend on, or pollute user-space naming.
YOU MUST NOT USE "uint32_t" when that may not be defined, and
user-space rules for when it is defined are arcane and totally
arbitrary.

- since the kernel cannot use those types for anything that is
visible to user space anyway, there has to be alternate names.
The tradition is to prepend two underscores, so the kernel would
have to use "__uint32_t" etc for its header files.

- at that point, there's no longer any valid argument that it's a
"standard type" (it ain't), and I personally find it a lot more
readable to just use the types that the kernel has always used:
__u8/__u16/__u32. For stuff that is only used for the kernel,
the shorter "u8/u16/u32" versions may be used.

In short: having the kernel use the same names as user space is ACTIVELY
BAD, exactly because those names have standards-defined visibility, which
means that the kernel _cannot_ use them in all places anyway. So don't
even _try_.

On the bigger question of what to do with kernel headers in general, let's
just make one thing clear: the kernel headers are for the kernel, and big
and painful re-organizations that don't help _existing_ user space are not
going to happen.

In particular, any re-organization that breaks _existing_ uses is totally
pointless. If you break existing uses, you might as well _not_ re-
organize, since if you consider kernel headers to be purely kernel-
internal (like they should be, but hey, reality trumps any wishes we might
have), then the current organization is perfectly fine.

So I think this whole discussion has been largely pointless. We undeniably
have existing users of kernel headers. That's just a fact. If we break
them, it doesn't _matter_ how the kernel headers look, and then "existing
practice" is about as good an organization as anything, and breaking
things just to break things is not something I'm in the least interested
in. "Beauty" comes secondary to "usefulness".

So I would encourage people to think about ways to clean up some of the
worst warts, but take into account:
- testing it out with whatever random collection of old distributions and
special applications is almost impossible. So every single step of the
way should be (a) small and (b) obviously not break any current users.
- cleanup just for the sake of cleanup always needs to take pain into
account. If you cannot make each small step "worth it", then just don't
do it. If the "cleanup" just adds another file and doesn't actually
_help_ anything that you can point to, it's not a cleanup, it's just an
exercise in wanking.

IOW, I seriously doubt any "let's reorganize header files just to make it
look good" _ever_ accomplished anything. But if there are _specific_
header files that have _specific_ problems, let's look at maybe solving
those. And if you cannot point to a specific problem with a suggested
specific solution, please don't cc me.

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

\
 
 \ /
  Last update: 2009-11-18 23:46    [from the cache]
©2003-2011 Jasper Spaans