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

["linux-os \(Dick Johnson\)" <linux-os@analogic.com>]

On Wed, 14 Sep 2005, Kyle Moffett wrote:

> On Sep 14, 2005, at 09:46:04, Bill Davidsen wrote:
>> H. Peter Anvin wrote:
>>> Followup to:  <20050902235833.GA28238@codepoet.org>
>>> By author:    Erik Andersen <andersen@codepoet.org>
>>> In newsgroup: linux.dev.kernel
>>>> <uClibc maintainer hat on>
>>>> That would be wonderful.
>>>> </off>
>>>>
>>>> It would be especially nice if everything targeting user space
>>>> were to use only all the nice standard ISO C99 types as defined
>>>> in include/stdint.h such as uint32_t and friends...
>>> Absolutely not.  This would be a POSIX namespace violation; they
>>> *must* use double-underscore types.
>>
>> Could you explain why you think it would be a violation to use
>> POSIX types instead of defining our own? That's what the types are
>> for, to avoid having everyone define some slightly conflicting types.
>>
>> The kernel predates C99, sort of, and it would be a massive but
>> valuable  task to figure out where a type is really, for instance,
>> 32 bits rather than "size of default int" in length, etc, and use
>> POSIX types where they are correct. Fewer things to maintain, and
>> would make it clear when something is 32 bits by default and when
>> it really must be 32 bits.
>
> Argh, it seems I'm going to be giving this example forever!  Here's
> why this won't work.  We want to have sys/stat.h do something like
> the following:
>
> # define __kabi_stat64 stat
> # include <kabi/stat.h>
> /* Now we expect struct stat to be defined with correct types */
>
> Since struct stat in that case uses fixed-bit-size types, the header
> fine <kabi/stat.h> needs to include a file providing those types.  If
> it used stdint.h types, such as uint32_t, then it would need to
> #include <stdint.h> or provide the stdint.h types itself.  In order
> to remain POSIX compliant, sys/stat.h must not include stdint.h or
> assume that stdint.h is included or that those types were defined by
> the user program.  Therefore, kabi/*.h cannot use the stdint.h types
> at all!  The solution is a separate file, kabi/types.h, which
> properly defines __kabi_[su]{8,16,32,64} which are safe to include
> and reuse anywhere.  Then sys/types.h would look like this:
>

No No. The solution is to do it right. If the standard says that
the header file can't include a header file defining the types used
within that header file (and I don't think the "standard" says that
at all), then the correct solution is to include the correct header file
in the user program. It is truly just that simple.

The whole purpose of POSIX types, a.k.a. ISO C99: 7.18 Integer types,
<stdint.h> was to PREVENT the crap like you describe. We do NOT
need, for instance....

 	uint8, u8, u8_t, __u8, _u8, -> inf., to
correctly define an unsigned 8-bit char type. All we need is the
POSIX type, uint8_t, nothing else.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.13 on an i686 machine (5589.53 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
I apologize for the following. I tried to kill it with the above dot :

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/