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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
