Re: linux/types.h - glibc interferences
On Thu, Aug 23, 2007 at 10:08:44PM +0200, Bastian Blank wrote: This is not properly fixable by the glibc. The attached patch fixes it in linux, but I'm unsure if this will not break other things like alternative libc. No productive disagreement. It will be included with a changed guard: #if defined(__KERNEL__) || __STDC_HOSTED__ == 0 !defined(__KERNEL_STRICT_NAMES) Bastian -- There are always alternatives. -- Spock, The Galileo Seven, stardate 2822.3 signature.asc Description: Digital signature
Re: linux/types.h - glibc interferences
On Fri, Aug 24, 2007 at 12:06:36AM +0200, Bastian Blank wrote: If there's userspace code that wants to get the kernel types under the standard posix names, why break that? Please provide a less strict fix which works. Userspace code can only use this definitions within a freestanding compiler without libc. I update the guard to defined __KERNEL__ || __STDC_HOSTED__ == 0. This way the kernel and the freestanding compiler can use them. Bastian -- The heart is not a logical organ. -- Dr. Janet Wallace, The Deadly Years, stardate 3479.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux/types.h - glibc interferences
On Fri, Aug 24, 2007 at 12:06:36AM +0200, Bastian Blank wrote: On Thu, Aug 23, 2007 at 02:46:14PM -0700, Steve Langasek wrote: Is there some specific reported issue that this change is intended to fix? I haven't noticed any complaints about the current behavior. #434040 and a hand full of packages on the buildd. What packages? Anyway, it's my understanding that userspace apps are never supposed to define __KERNEL__ and doing so with linux-libc-dev gives broken includes, so in terms of overall design this change looks wrong to me (or at least, gratuitously strict). __KERNEL__-only parts of the headers are filtered out for linux-libc-dev. If there's userspace code that wants to get the kernel types under the standard posix names, why break that? Please provide a less strict fix which works. Userspace code can only use this definitions within a freestanding compiler without libc. Well, it's hard to suggest a less strict fix without knowing what needs fixing. :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux/types.h - glibc interferences
On Fri, Aug 24, 2007 at 01:14:17AM -0700, Steve Langasek wrote: On Fri, Aug 24, 2007 at 12:06:36AM +0200, Bastian Blank wrote: #434040 and a hand full of packages on the buildd. What packages? Several. No further information available without manual checking. I expect that several hundred packages may be affected. linux-kernel-headers had a crude workaround, which is not better. Well, it's hard to suggest a less strict fix without knowing what needs fixing. :) linux/types.h and the other glibc/gcc headers must not clash, even if features.h is not included and __KERNEL_STRICT_NAMES not set. Bastian -- The joys of love made her human and the agonies of love destroyed her. -- Spock, Requiem for Methuselah, stardate 5842.8 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
linux/types.h - glibc interferences
Hi folks
linux/types.h exports some POSIX types. It can be asked to stop this
with __KERNEL_STRICT_NAMES. features.h defines this. So currently
anything works if features.h is included before linux/types.h.
This is not properly fixable by the glibc. The attached patch fixes it
in linux, but I'm unsure if this will not break other things like
alternative libc.
Bastian
--
You can't evaluate a man by logic alone.
-- McCoy, I, Mudd, stardate 4513.3
diff --git a/include/linux/types.h b/include/linux/types.h
index 0351bf2..a9779d6 100644
--- a/include/linux/types.h
+++ b/include/linux/types.h
@@ -14,10 +14,10 @@
#include linux/posix_types.h
#include asm/types.h
-#ifndef __KERNEL_STRICT_NAMES
-
typedef __u32 __kernel_dev_t;
+#ifdef __KERNEL__
+
typedef __kernel_fd_set fd_set;
typedef __kernel_dev_t dev_t;
typedef __kernel_ino_t ino_t;
@@ -32,7 +32,6 @@ typedef __kernel_timer_t timer_t;
typedef __kernel_clockid_t clockid_t;
typedef __kernel_mqd_t mqd_t;
-#ifdef __KERNEL__
typedef _Bool bool;
typedef __kernel_uid32_t uid_t;
@@ -46,51 +45,14 @@ typedef __kernel_old_uid_t old_uid_t;
typedef __kernel_old_gid_t old_gid_t;
#endif /* CONFIG_UID16 */
-/* libc5 includes this file to define uid_t, thus uid_t can never change
- * when it is included by non-kernel code
- */
-#else
-typedef __kernel_uid_t uid_t;
-typedef __kernel_gid_t gid_t;
-#endif /* __KERNEL__ */
-
-#if defined(__GNUC__) !defined(__STRICT_ANSI__)
typedef __kernel_loff_t loff_t;
-#endif
-/*
- * The following typedefs are also protected by individual ifdefs for
- * historical reasons:
- */
-#ifndef _SIZE_T
-#define _SIZE_T
typedef __kernel_size_t size_t;
-#endif
-
-#ifndef _SSIZE_T
-#define _SSIZE_T
typedef __kernel_ssize_t ssize_t;
-#endif
-
-#ifndef _PTRDIFF_T
-#define _PTRDIFF_T
typedef __kernel_ptrdiff_t ptrdiff_t;
-#endif
-
-#ifndef _TIME_T
-#define _TIME_T
typedef __kernel_time_t time_t;
-#endif
-
-#ifndef _CLOCK_T
-#define _CLOCK_T
typedef __kernel_clock_t clock_t;
-#endif
-
-#ifndef _CADDR_T
-#define _CADDR_T
typedef __kernel_caddr_t caddr_t;
-#endif
/* bsd */
typedef unsigned char u_char;
@@ -104,27 +66,18 @@ typedef unsigned short ushort;
typedef unsigned int uint;
typedef unsigned long ulong;
-#ifndef __BIT_TYPES_DEFINED__
-#define __BIT_TYPES_DEFINED__
-
+typedef __u8 uint8_t;
typedef __u8 u_int8_t;
typedef __s8 int8_t;
+typedef __u16 uint16_t;
typedef __u16 u_int16_t;
typedef __s16 int16_t;
+typedef __u32 uint32_t;
typedef __u32 u_int32_t;
typedef __s32 int32_t;
-
-#endif /* !(__BIT_TYPES_DEFINED__) */
-
-typedef __u8 uint8_t;
-typedef __u16 uint16_t;
-typedef __u32 uint32_t;
-
-#if defined(__GNUC__) !defined(__STRICT_ANSI__)
typedef __u64 uint64_t;
typedef __u64 u_int64_t;
typedef __s64 int64_t;
-#endif
/* this is a special 64bit data type that is 8-byte aligned */
#define aligned_u64 unsigned long long __attribute__((aligned(8)))
@@ -160,7 +113,7 @@ typedef unsigned long blkcnt_t;
#define pgoff_t unsigned long
#endif
-#endif /* __KERNEL_STRICT_NAMES */
+#endif /* __KERNEL__ */
/*
* Below are truly Linux-specific types that should never collide with
@@ -182,10 +135,8 @@ typedef __u16 __bitwise __le16;
typedef __u16 __bitwise __be16;
typedef __u32 __bitwise __le32;
typedef __u32 __bitwise __be32;
-#if defined(__GNUC__) !defined(__STRICT_ANSI__)
-typedef __u64 __bitwise __le64;
-typedef __u64 __bitwise __be64;
-#endif
+__extension__ typedef __u64 __bitwise __le64;
+__extension__ typedef __u64 __bitwise __be64;
typedef __u16 __bitwise __sum16;
typedef __u32 __bitwise __wsum;
@@ -198,8 +149,6 @@ typedef u64 resource_size_t;
typedef u32 resource_size_t;
#endif
-#endif /* __KERNEL__ */
-
struct ustat {
__kernel_daddr_t f_tfree;
__kernel_ino_t f_tinode;
@@ -207,4 +156,6 @@ struct ustat {
char f_fpack[6];
};
+#endif /* __KERNEL__ */
+
#endif /* _LINUX_TYPES_H */
Re: linux/types.h - glibc interferences
On Thu, Aug 23, 2007 at 02:46:14PM -0700, Steve Langasek wrote: Is there some specific reported issue that this change is intended to fix? I haven't noticed any complaints about the current behavior. #434040 and a hand full of packages on the buildd. Anyway, it's my understanding that userspace apps are never supposed to define __KERNEL__ and doing so with linux-libc-dev gives broken includes, so in terms of overall design this change looks wrong to me (or at least, gratuitously strict). __KERNEL__-only parts of the headers are filtered out for linux-libc-dev. If there's userspace code that wants to get the kernel types under the standard posix names, why break that? Please provide a less strict fix which works. Userspace code can only use this definitions within a freestanding compiler without libc. (For an example of code that probably breaks with this change, I offer you aboot, the alpha bootloader; it's not great code, but we have to maintain it all the same...) Thats what I expected. Bastian -- A little suffering is good for the soul. -- Kirk, The Corbomite Maneuver, stardate 1514.0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux/types.h - glibc interferences
On Thu, Aug 23, 2007 at 10:08:44PM +0200, Bastian Blank wrote: linux/types.h exports some POSIX types. It can be asked to stop this with __KERNEL_STRICT_NAMES. features.h defines this. So currently anything works if features.h is included before linux/types.h. This is not properly fixable by the glibc. The attached patch fixes it in linux, but I'm unsure if this will not break other things like alternative libc. Is there some specific reported issue that this change is intended to fix? I haven't noticed any complaints about the current behavior. I assume this isn't intended as the fix for 429064, since 429064 is reporting an issue with a kernel type which is currently *not* guarded with __KERNEL_STRICT_NAMES; your patch fixes this, but only as a side-effect. Anyway, it's my understanding that userspace apps are never supposed to define __KERNEL__ and doing so with linux-libc-dev gives broken includes, so in terms of overall design this change looks wrong to me (or at least, gratuitously strict). If there's userspace code that wants to get the kernel types under the standard posix names, why break that? (For an example of code that probably breaks with this change, I offer you aboot, the alpha bootloader; it's not great code, but we have to maintain it all the same...) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
