Re: [RFC] Splitting out kernel<=>userspace ABI headers

[Kyle Moffett]

On Sep 2, 2005, at 20:34:11, H. Peter Anvin wrote:
> Kyle Moffett wrote:
> > I would actually be more inclined to provide and use types like
> > _kabi_{s,u}{8,16,32,64}, etc.  Then the glibc/klibc/etc authors would
> > have the option of just doing "typedef _kabi_u32 uint32_t;" in their
> > header files.
>
> They have to be *double-underscore*.
>
> We have that.  They're called __[su]{8,16,32,64}.

I realize this completely.  The point of moving to kabi/* and kcore/*
would be to remove the dependence of userspace-accessible headers on
kernel-internal stuff.  As I see it, part of that means exporting a
reasonably clean and straightforward API from kabi/kcore, including a
decent namespace prefix.  The goal would be something that the kernel
headers could map to types useable in kernel code, that various *libc
in userspace could map to POSIX types, and that would have a nice
prefix to be namespace clean and avoid the risk of contamination.
Given this set of goals, I think that something like the below would
probably work and satisfy the needs of both *libc and the kernel:



/* kcore/types.h */
typedef unsigned char __kabi_u8;
typedef   signed char __kabi_s8;
typedef [...]



/* linux/types.h */
#include <kcore/types.h>

#ifndef __KERNEL__
# warning "Insert some kind of deprecation warning here
#endif

  /* These for compatibility only.  When the last ABI headers move
     to kcore or kabi, these should go in __KERNEL__ */
typedef __kabi_u8 __u8;
typedef __kabi_s8 __s8;
[...]

#ifdef __KERNEL__
typedef __kabi_u8 u8;
typedef __kabi_s8 s8;
#endif



/* stdint.h */
#include <kcore/types.h>
typedef __kabi_u8 uint8_t;
typedef __kabi_s8 int8_t;
[...]



Cheers,
Kyle Moffett

--
There is no way to make Linux robust with unreliable memory subsystems,
sorry.  It would be like trying to make a human more robust with an
unreliable O2 supply. Memory just has to work.
  -- Andi Kleen


-
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/