From: Kyle Moffett <mrmacman_g4@mac.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFC] Splitting out kernel<=>userspace ABI headers
Date: Fri, 2 Sep 2005 20:50:55 -0400 [thread overview]
Message-ID: <32454DD9-7E83-4FC0-AA7F-E24930CB7809@mac.com> (raw)
In-Reply-To: <4318EF83.1010401@zytor.com>
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
next prev parent reply other threads:[~2005-09-03 0:51 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-02 3:00 Kyle Moffett
2005-09-02 13:41 ` Erik Andersen
2005-09-02 20:51 ` Kyle Moffett
2005-09-02 23:58 ` Erik Andersen
2005-09-03 0:07 ` H. Peter Anvin
2005-09-03 0:30 ` Kyle Moffett
2005-09-03 0:34 ` H. Peter Anvin
2005-09-03 0:50 ` Kyle Moffett [this message]
2005-09-03 4:28 ` Erik Andersen
2005-09-03 5:22 ` H. Peter Anvin
2005-09-03 5:50 ` Erik Andersen
2005-09-03 5:53 ` H. Peter Anvin
2005-09-03 6:41 ` Erik Andersen
2005-09-03 15:01 ` H. Peter Anvin
2005-09-03 15:19 ` H. Peter Anvin
2005-09-03 16:55 ` Kyle Moffett
2005-09-05 16:35 ` H. Peter Anvin
2005-09-05 23:28 ` Kyle Moffett
2005-09-06 1:29 ` [RFC][MEGAPATCH] Change __ASSEMBLY__ to __ASSEMBLER__ (defined by GCC from 2.95 to current CVS) Kyle Moffett
2005-09-10 8:40 ` Kyle Moffett
2005-09-10 8:45 ` Andrew Morton
2005-09-10 17:38 ` Kyle Moffett
2005-09-10 22:04 ` Andrew Morton
2005-09-11 0:33 ` Kyle Moffett
2005-09-11 0:48 ` Andrew Morton
2005-09-11 3:15 ` Kyle Moffett
2005-09-12 8:09 ` Paul Jackson
2005-09-12 15:19 ` H. Peter Anvin
2005-09-12 15:47 ` Paul Jackson
2005-09-12 17:17 ` Sam Ravnborg
2005-09-12 21:14 ` Paul Jackson
2005-09-12 21:39 ` Kyle Moffett
2005-09-12 17:18 ` H. Peter Anvin
2005-09-12 17:51 ` Kyle Moffett
2005-09-12 21:04 ` Paul Jackson
2005-09-14 13:56 ` Bill Davidsen
2005-09-15 21:53 ` Jeremy Fitzhardinge
2005-09-03 5:55 ` [RFC] Splitting out kernel<=>userspace ABI headers Kyle Moffett
2005-09-03 5:57 ` H. Peter Anvin
2005-09-03 6:05 ` Kyle Moffett
2005-09-03 15:36 ` Denis Vlasenko
2005-09-03 16:33 ` Kyle Moffett
2005-09-03 16:51 ` Denis Vlasenko
2005-09-14 13:46 ` Bill Davidsen
2005-09-14 17:01 ` Sam Ravnborg
2005-09-14 17:01 ` H. Peter Anvin
2005-09-14 18:14 ` Kyle Moffett
2005-09-14 19:09 ` linux-os (Dick Johnson)
2005-09-14 19:20 ` H. Peter Anvin
2005-09-14 19:46 ` Kyle Moffett
2005-09-02 21:42 ` Jeff Dike
2005-09-02 21:55 ` H. Peter Anvin
2005-09-02 22:44 ` Kyle Moffett
2005-09-02 23:24 ` H. Peter Anvin
2005-09-02 23:41 ` Kyle Moffett
2005-09-02 23:53 ` H. Peter Anvin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=32454DD9-7E83-4FC0-AA7F-E24930CB7809@mac.com \
--to=mrmacman_g4@mac.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®