From: Kyle Moffett <mrmacman_g4@mac.com>
To: Denis Vlasenko <vda@ilport.com.ua>
Cc: andersen@codepoet.org, "H. Peter Anvin" <hpa@zytor.com>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC] Splitting out kernel<=>userspace ABI headers
Date: Sat, 3 Sep 2005 12:33:53 -0400 [thread overview]
Message-ID: <EE55C4EC-424E-45B8-8BFD-B8C719730C13@mac.com> (raw)
In-Reply-To: <200509031836.22357.vda@ilport.com.ua>
On Sep 3, 2005, at 11:36:22, Denis Vlasenko wrote:
> Is this an exercise in academia? Userspace app which defines
> uint32_t to anything different than 'typedef <appropriate int type>'
> deserves the punishment, and one which does have such typedef
> instead of #include stdint.h will not notice.
That's not the issue. Say I do this (which is perfectly valid on
most platforms):
typedef unsigned int uint32_t;
#include <linux/loop.h>
What exactly should happen? If linux/loop.h includes stdint.h to get
uint32_t, then I'll get duplicate definition errors. If it omits
stdint.h, then uint16_t won't be defined (because the userspace app
doesn't think that it needs it) and I'll get undefined type errors.
Either way, depending on the existence or nonexistence of the POSIX
types in userspace-accessible kernel headers is not viable.
> All these u32, uint32_t, __u32 end up typedef-ing to same
> integer type anyway...
The point is to provide a type that _isn't_ in some standard so that
_we_ can define its inclusion rules. If the standards had gone and
defined "Userspace must include stdint.h or define _all_ types
appropriately", then we would not have had this issue, but many apps
in userspace would cease to compile on standards compliant platforms.
Cheers,
Kyle Moffett
--
Somone asked me why I work on this free (http://www.fsf.org/philosophy/)
software stuff and not get a real job. Charles Shultz had the best
answer:
"Why do musicians compose symphonies and poets write poems? They do
it because
life wouldn't have any meaning for them if they didn't. That's why I
draw
cartoons. It's my life."
-- Charles Shultz
next prev parent reply other threads:[~2005-09-03 16:34 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
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 [this message]
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=EE55C4EC-424E-45B8-8BFD-B8C719730C13@mac.com \
--to=mrmacman_g4@mac.com \
--cc=andersen@codepoet.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=vda@ilport.com.ua \
/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®