Re: [RFC] Splitting kernel headers and deprecating __KERNEL__

[Werner Almesberger]

Krzysztof Halasa wrote:
> Not sure about this. I think such types should be defined by the
> kernel, for it's use only. The libc (and any other userspace
> software) may probably use them (if they have to), but must not
> (re)define them.

That's not what should be happening there: if the kernel only uses
__u32 and friends but never uint32_t et al. at an interface,

typedef __u32 uint32_t;

should be a perfectly safe thing for glibc's stdint.h to do.

> The userspace should probably best use standard types.

Yes.

> This is
> userspace to know if their uint32_t has standard meaning equivalent
> to __u32 or if it's actually a function name.

Yes, but that's decided by whether you include stdint.h or
anything that has the effect of including stdint.h. What I'm
saying is that there should be a guarantee that __u32 and
uint32_t are always identical types. If they are merely
assignment-compatible, you run into problems like this

/* somewhere in a kernel-to-glibc interface (on 32 bit) */
typedef unsigned int __u32;
...
static __u32 foo;

/* elsewhere, in glibc (on 32 bit) */
typedef unsigned long uint32_t;
...
static uint32_t bar;

/* finally, in the application */
if (&foo == &bar)
	/* do something */;

warning: comparison of distinct pointer types lacks a cast

> and then userspace.c (libc et al) should:
> 
> #include linux/headers.h
> 
> str1 v;
> uint32_t variable = v.var;

Interfaces are normally specified with the explicit data type of
each item, in particular struct members. The masses will probably
look for solid branches instead of olive twigs for you if you try
to break this kind of assurance :-)

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa@xxxxxxxxxxxxxxx /
/_http://www.almesberger.net/____________________________________________/
-
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/