mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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



  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®