From: "H.J. Lu" <hjl.to...@gmail.com>

Replace long with __kernel_long_t in struct rusage and replace
unsigned long with __kernel_ulong_t in struct rlimit for usr space.

Signed-off-by: H.J. Lu <hjl.to...@gmail.com>
---
 include/linux/resource.h |   32 ++++++++++++++++----------------
 1 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/include/linux/resource.h b/include/linux/resource.h
index d01c96c..38bbb6a 100644
--- a/include/linux/resource.h
+++ b/include/linux/resource.h
@@ -23,25 +23,25 @@
 struct rusage {
        struct timeval ru_utime;        /* user time used */
        struct timeval ru_stime;        /* system time used */
-       long    ru_maxrss;              /* maximum resident set size */
-       long    ru_ixrss;               /* integral shared memory size */
-       long    ru_idrss;               /* integral unshared data size */
-       long    ru_isrss;               /* integral unshared stack size */
-       long    ru_minflt;              /* page reclaims */
-       long    ru_majflt;              /* page faults */
-       long    ru_nswap;               /* swaps */
-       long    ru_inblock;             /* block input operations */
-       long    ru_oublock;             /* block output operations */
-       long    ru_msgsnd;              /* messages sent */
-       long    ru_msgrcv;              /* messages received */
-       long    ru_nsignals;            /* signals received */
-       long    ru_nvcsw;               /* voluntary context switches */
-       long    ru_nivcsw;              /* involuntary " */
+       __kernel_long_t ru_maxrss;      /* maximum resident set size */
+       __kernel_long_t ru_ixrss;       /* integral shared memory size */
+       __kernel_long_t ru_idrss;       /* integral unshared data size */
+       __kernel_long_t ru_isrss;       /* integral unshared stack size */
+       __kernel_long_t ru_minflt;      /* page reclaims */
+       __kernel_long_t ru_majflt;      /* page faults */
+       __kernel_long_t ru_nswap;       /* swaps */
+       __kernel_long_t ru_inblock;     /* block input operations */
+       __kernel_long_t ru_oublock;     /* block output operations */
+       __kernel_long_t ru_msgsnd;      /* messages sent */
+       __kernel_long_t ru_msgrcv;      /* messages received */
+       __kernel_long_t ru_nsignals;    /* signals received */
+       __kernel_long_t ru_nvcsw;       /* voluntary context switches */
+       __kernel_long_t ru_nivcsw;      /* involuntary " */
 };

 struct rlimit {
-       unsigned long   rlim_cur;
-       unsigned long   rlim_max;
+       __kernel_ulong_t rlim_cur;
+       __kernel_ulong_t rlim_max;
 };

 #define RLIM64_INFINITY                (~0ULL)
--
1.7.6.5

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

From: "H.J. Lu" <hjl.to...@gmail.com>

Replace unsigned long with __kernel_ulong_t in struct shm_info for
user space.

Signed-off-by: H.J. Lu <hjl.to...@gmail.com>
---
 include/linux/shm.h |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/linux/shm.h b/include/linux/shm.h
index 92808b8..6cd9510 100644
--- a/include/linux/shm.h
+++ b/include/linux/shm.h
@@ -75,11 +75,11 @@ struct      shminfo {

 struct shm_info {
        int used_ids;
-       unsigned long shm_tot;  /* total allocated shm */
-       unsigned long shm_rss;  /* total resident shm */
-       unsigned long shm_swp;  /* total swapped shm */
-       unsigned long swap_attempts;
-       unsigned long swap_successes;
+       __kernel_ulong_t shm_tot;       /* total allocated shm */
+       __kernel_ulong_t shm_rss;       /* total resident shm */
+       __kernel_ulong_t shm_swp;       /* total swapped shm */
+       __kernel_ulong_t swap_attempts;
+       __kernel_ulong_t swap_successes;
 };

 #ifdef __KERNEL__
--
1.7.6.5

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

From: "H.J. Lu" <hjl.to...@gmail.com>

Replace unsigned long with __kernel_ulong_t in struct ipc64_perm for
user space.

Signed-off-by: H.J. Lu <hjl.to...@gmail.com>
---
 include/asm-generic/ipcbuf.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/asm-generic/ipcbuf.h b/include/asm-generic/ipcbuf.h
index 76982b2..3dbcc1e 100644
--- a/include/asm-generic/ipcbuf.h
+++ b/include/asm-generic/ipcbuf.h
@@ -27,8 +27,8 @@ struct ipc64_perm {
        unsigned char           __pad1[4 - sizeof(__kernel_mode_t)];
        unsigned short          seq;
        unsigned short          __pad2;
-       unsigned long           __unused1;
-       unsigned long           __unused2;
+       __kernel_ulong_t        __unused1;
+       __kernel_ulong_t        __unused2;
 };

 #endif /* __ASM_GENERIC_IPCBUF_H */
--
1.7.6.5

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

From: "H.J. Lu" <hjl.to...@gmail.com>

Replace long with __kernel_long_t in struct msgbuf for user space.

Signed-off-by: H.J. Lu <hjl.to...@gmail.com>
---
 include/linux/msg.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/msg.h b/include/linux/msg.h
index 56abf15..c5d21c1 100644
--- a/include/linux/msg.h
+++ b/include/linux/msg.h
@@ -33,8 +33,8 @@ struct msqid_ds {

 /* message buffer for msgsnd and msgrcv calls */
 struct msgbuf {
-       long mtype;         /* type of message */
-       char mtext[1];      /* message text */
+       __kernel_long_t mtype;  /* type of message */
+       char mtext[1];          /* message text */
 };

 /* buffer for msgctl calls IPC_INFO, MSG_INFO */
--
1.7.6.5

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

From: "H.J. Lu" <hjl.to...@gmail.com>

Include <linux/types.h>.  Replace unsigned long/long with
__kernel_ulong_t/__kernel_long_t in x86-64 struct stat for user space.

Signed-off-by: H.J. Lu <hjl.to...@gmail.com>
---
 arch/x86/include/asm/stat.h |   42 ++++++++++++++++++++++--------------------
 1 files changed, 22 insertions(+), 20 deletions(-)

diff --git a/arch/x86/include/asm/stat.h b/arch/x86/include/asm/stat.h
index e0b1d9b..6d99f66 100644
--- a/arch/x86/include/asm/stat.h
+++ b/arch/x86/include/asm/stat.h
@@ -3,6 +3,8 @@

 #define STAT_HAVE_NSEC 1

+#include <linux/types.h>
+
 #ifdef __i386__
 struct stat {
        unsigned long  st_dev;
@@ -66,26 +68,26 @@ struct stat64 {
 #else /* __i386__ */

 struct stat {
-       unsigned long   st_dev;
-       unsigned long   st_ino;
-       unsigned long   st_nlink;
-
-       unsigned int    st_mode;
-       unsigned int    st_uid;
-       unsigned int    st_gid;
-       unsigned int    __pad0;
-       unsigned long   st_rdev;
-       long            st_size;
-       long            st_blksize;
-       long            st_blocks;      /* Number 512-byte blocks allocated. */
-
-       unsigned long   st_atime;
-       unsigned long   st_atime_nsec;
-       unsigned long   st_mtime;
-       unsigned long   st_mtime_nsec;
-       unsigned long   st_ctime;
-       unsigned long   st_ctime_nsec;
-       long            __unused[3];
+       __kernel_ulong_t st_dev;
+       __kernel_ulong_t st_ino;
+       __kernel_ulong_t st_nlink;
+
+       unsigned int     st_mode;
+       unsigned int     st_uid;
+       unsigned int     st_gid;
+       unsigned int     __pad0;
+       __kernel_ulong_t st_rdev;
+       __kernel_long_t  st_size;
+       __kernel_long_t  st_blksize;
+       __kernel_long_t  st_blocks;     /* Number 512-byte blocks allocated. */
+
+       __kernel_ulong_t st_atime;
+       __kernel_ulong_t st_atime_nsec;
+       __kernel_ulong_t st_mtime;
+       __kernel_ulong_t st_mtime_nsec;
+       __kernel_ulong_t st_ctime;
+       __kernel_ulong_t st_ctime_nsec;
+       __kernel_long_t  __unused[3];
 };
 #endif

--
1.7.6.5

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

From: "H.J. Lu" <hjl.to...@gmail.com>

Replace long with __kernel_long_t in struct mq_attr for user space.

Signed-off-by: H.J. Lu <hjl.to...@gmail.com>
---
 include/linux/mqueue.h |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/linux/mqueue.h b/include/linux/mqueue.h
index 8b5a796..d89a735 100644
--- a/include/linux/mqueue.h
+++ b/include/linux/mqueue.h
@@ -23,11 +23,11 @@
 #define MQ_BYTES_MAX   819200

 struct mq_attr {
-       long    mq_flags;       /* message queue flags                  */
-       long    mq_maxmsg;      /* maximum number of messages           */
-       long    mq_msgsize;     /* maximum message size                 */
-       long    mq_curmsgs;     /* number of messages currently queued  */
-       long    __reserved[4];  /* ignored for input, zeroed for output */
+       __kernel_long_t mq_flags;       /* message queue flags                  */
+       __kernel_long_t mq_maxmsg;      /* maximum number of messages           */
+       __kernel_long_t mq_msgsize;     /* maximum message size                 */
+       __kernel_long_t mq_curmsgs;     /* number of messages currently queued  */
+       __kernel_long_t __reserved[4];  /* ignored for input, zeroed for output */
 };

 /*
--
1.7.6.5

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

From: "H.J. Lu" <hjl.to...@gmail.com>

Replace unsigned long with __kernel_ulong_t in struct shmid64_ds and
struct shminfo64 for user space.

Signed-off-by: H.J. Lu <hjl.to...@gmail.com>
---
 include/asm-generic/shmbuf.h |   24 ++++++++++++------------
 1 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/include/asm-generic/shmbuf.h b/include/asm-generic/shmbuf.h
index 5768fa6..7e9fb2f 100644
--- a/include/asm-generic/shmbuf.h
+++ b/include/asm-generic/shmbuf.h
@@ -39,21 +39,21 @@ struct shmid64_ds {
 #endif
        __kernel_pid_t          shm_cpid;       /* pid of creator */
        __kernel_pid_t          shm_lpid;       /* pid of last operator */
-       unsigned long           shm_nattch;     /* no. of current attaches */
-       unsigned long           __unused4;
-       unsigned long           __unused5;
+       __kernel_ulong_t        shm_nattch;     /* no. of current attaches */
+       __kernel_ulong_t        __unused4;
+       __kernel_ulong_t        __unused5;
 };

 struct shminfo64 {
-       unsigned long   shmmax;
-       unsigned long   shmmin;
-       unsigned long   shmmni;
-       unsigned long   shmseg;
-       unsigned long   shmall;
-       unsigned long   __unused1;
-       unsigned long   __unused2;
-       unsigned long   __unused3;
-       unsigned long   __unused4;
+       __kernel_ulong_t        shmmax;
+       __kernel_ulong_t        shmmin;
+       __kernel_ulong_t        shmmni;
+       __kernel_ulong_t        shmseg;
+       __kernel_ulong_t        shmall;
+       __kernel_ulong_t        __unused1;
+       __kernel_ulong_t        __unused2;
+       __kernel_ulong_t        __unused3;
+       __kernel_ulong_t        __unused4;
 };

 #endif /* __ASM_GENERIC_SHMBUF_H */
--
1.7.6.5

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

From: H.J. Lu <hjl.to...@gmail.com>

This patch set changes a number of places where the kernel headers are
exported to user space and currently use explicit "long" or "unsigned
long" to use __kernel_[u]long_t in order to be compatible with the x32
user space ABI.  These location are places where x32 uses the x86-64
ABI.

It is quite possible that some, or even all, of these locations should
really use dedicated types, but in the meantime this gives the correct
results which the current headers do not.

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

From: "H.J. Lu" <hjl.to...@gmail.com>

Replace long with __kernel_long_t in struct timex for user space.

Signed-off-by: H.J. Lu <hjl.to...@gmail.com>
---
 include/linux/timex.h |   34 +++++++++++++++++-----------------
 1 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/include/linux/timex.h b/include/linux/timex.h
index 99bc88b..22c57ac 100644
--- a/include/linux/timex.h
+++ b/include/linux/timex.h
@@ -63,27 +63,27 @@
  */
 struct timex {
        unsigned int modes;     /* mode selector */
-       long offset;            /* time offset (usec) */
-       long freq;              /* frequency offset (scaled ppm) */
-       long maxerror;          /* maximum error (usec) */
-       long esterror;          /* estimated error (usec) */
+       __kernel_long_t offset; /* time offset (usec) */
+       __kernel_long_t freq;   /* frequency offset (scaled ppm) */
+       __kernel_long_t maxerror; /* maximum error (usec) */
+       __kernel_long_t esterror; /* estimated error (usec) */
        int status;             /* clock command/status */
-       long constant;          /* pll time constant */
-       long precision;         /* clock precision (usec) (read only) */
-       long tolerance;         /* clock frequency tolerance (ppm)
-                                * (read only)
-                                */
+       __kernel_long_t constant; /* pll time constant */
+       __kernel_long_t precision; /* clock precision (usec) (read only) */
+       __kernel_long_t tolerance; /* clock frequency tolerance (ppm)
+                                   * (read only)
+                                   */
        struct timeval time;    /* (read only, except for ADJ_SETOFFSET) */
-       long tick;              /* (modified) usecs between clock ticks */
+       __kernel_long_t tick;   /* (modified) usecs between clock ticks */

-       long ppsfreq;           /* pps frequency (scaled ppm) (ro) */
-       long jitter;            /* pps jitter (us) (ro) */
+       __kernel_long_t ppsfreq; /* pps frequency (scaled ppm) (ro) */
+       __kernel_long_t jitter; /* pps jitter (us) (ro) */
        int shift;              /* interval duration (s) (shift) (ro) */
-       long stabil;            /* pps stability (scaled ppm) (ro) */
-       long jitcnt;            /* jitter limit exceeded (ro) */
-       long calcnt;            /* calibration intervals (ro) */
-       long errcnt;            /* calibration errors (ro) */
-       long stbcnt;            /* stability limit exceeded (ro) */
+       __kernel_long_t stabil; /* pps stability (scaled ppm) (ro) */
+       __kernel_long_t jitcnt; /* jitter limit exceeded (ro) */
+       __kernel_long_t calcnt; /* calibration intervals (ro) */
+       __kernel_long_t errcnt; /* calibration errors (ro) */
+       __kernel_long_t stbcnt; /* stability limit exceeded (ro) */

        int tai;                /* TAI offset (ro) */

--
1.7.6.5

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

From: "H.J. Lu" <hjl.to...@gmail.com>

Replace unsigned long with __kernel_ulong_t in x86 struct semid64_ds
for user space.

Signed-off-by: H.J. Lu <hjl.to...@gmail.com>
---
 arch/x86/include/asm/sembuf.h |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/x86/include/asm/sembuf.h b/arch/x86/include/asm/sembuf.h
index ee50c80..cc2d6a3 100644
--- a/arch/x86/include/asm/sembuf.h
+++ b/arch/x86/include/asm/sembuf.h
@@ -13,12 +13,12 @@
 struct semid64_ds {
        struct ipc64_perm sem_perm;     /* permissions .. see ipc.h */
        __kernel_time_t sem_otime;      /* last semop time */
-       unsigned long   __unused1;
+       __kernel_ulong_t __unused1;
        __kernel_time_t sem_ctime;      /* last change time */
-       unsigned long   __unused2;
-       unsigned long   sem_nsems;      /* no. of semaphores in array */
-       unsigned long   __unused3;
-       unsigned long   __unused4;
+       __kernel_ulong_t __unused2;
+       __kernel_ulong_t sem_nsems;     /* no. of semaphores in array */
+       __kernel_ulong_t __unused3;
+       __kernel_ulong_t __unused4;
 };

 #endif /* _ASM_X86_SEMBUF_H */
--
1.7.6.5

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

From: "H.J. Lu" <hjl.to...@gmail.com>

Replace unsigned long with __kernel_ulong_t in struct msqid64_ds for
user space.  Don't change unsigned long when __BITS_PER_LONG != 64
since __kernel_ulong_t == unsigned long in this case.

Signed-off-by: H.J. Lu <hjl.to...@gmail.com>
---
 include/asm-generic/msgbuf.h |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/asm-generic/msgbuf.h b/include/asm-generic/msgbuf.h
index aec850d..f55ecc4 100644
--- a/include/asm-generic/msgbuf.h
+++ b/include/asm-generic/msgbuf.h
@@ -35,13 +35,13 @@ struct msqid64_ds {
 #if __BITS_PER_LONG != 64
        unsigned long   __unused3;
 #endif
-       unsigned long  msg_cbytes;      /* current number of bytes on queue */
-       unsigned long  msg_qnum;        /* number of messages in queue */
-       unsigned long  msg_qbytes;      /* max number of bytes on queue */
+       __kernel_ulong_t msg_cbytes;    /* current number of bytes on queue */
+       __kernel_ulong_t msg_qnum;      /* number of messages in queue */
+       __kernel_ulong_t msg_qbytes;    /* max number of bytes on queue */
        __kernel_pid_t msg_lspid;       /* pid of last msgsnd */
        __kernel_pid_t msg_lrpid;       /* last receive pid */
-       unsigned long  __unused4;
-       unsigned long  __unused5;
+       __kernel_ulong_t __unused4;
+       __kernel_ulong_t __unused5;
 };

 #endif /* __ASM_GENERIC_MSGBUF_H */
--
1.7.6.5

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

I absolutely detest these types.

I realize that we already have a few users, but just looking at these
diffs *hurts*. It's disgusting.

The whole __kernel_ prefix was a mistake, but it at least makes sense
for certain things where it is really about some random kernel choice
(ie __kernel_pid_t). Even there I despise it, because it's not really
about "kernel choice", it's about just the real native type for uid_t
- the fact that user-mode then occasionally screwed up because glibc
has chosen crazy extended types is really not a "kernel" issue at all.
So the naming in general is painful.

When it comes to the x32 thing I think it's *doubly* wrong, because
this isn't even about a "kernel choice". It's damn well the native
machine word-size. The fact that a limited user-mode ABI then limits
"long" to 32-bit is not the kernels problem.

So I'd really like to see some discussion about naming. What does this
have to do with "kernel"? Nothing. It's the native word-size of the
machine, for crying out loud. The fact that some user interfaces may
limit themselves is not a "user mode vs kernel" thing.

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

On 05/17/2012 03:32 PM, Linus Torvalds wrote:

It also puts a clear line between the kernel and user space namespaces,
which has been an ongoing problem (we *still* haven't cleaned out some
namespace pollution in the i386 <asm/signal.h> for example.)

That being said, this is a lot like the __u* and __s* types which we use
instead of <stdint.h> for similar reasons.  I don't know if
__ulong/__slong or __uword/__sword would be better here?

        -hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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

On Thu, May 17, 2012 at 3:41 PM, H. Peter Anvin <h...@zytor.com> wrote:

Yes, I do think this is closer to the "__u32" kind of usage, and in
general I tend to think that's true of most of the __kernel_ prefix
things. There is very little "kernely" things about it.

Yes, we have to have the double underscore (or single+capitalized),
but I think that at least personally, I'd be happier with just
"__long" and "__ulong".

I think __word would be good too, *except* for the fact that
especially in x86 land, I think there's the legacy confusion with
"word" being 16-bit. Ugh.

So I don't know. I just do know that I don't see the point in that
"__kernel_" prefix.

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

On 05/17/2012 03:50 PM, Linus Torvalds wrote:

The only think "kernely" about it is that it describes the kernel ABI.

I would suggest __slong and __ulong then, to keep with the __[su]*
namespace, or does the extra "s" look too much like crap?

        -hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

On Thu, May 17, 2012 at 3:50 PM, Linus Torvalds

Looking at the x32 case, I have to say that "long" in general looks
horrible. Especially when we have things like

  typedef long long __kernel_long_t;

(and __long really wouldn't look any nicer). Any sane person would go
"Eww" at looking at that - we're using 'long long' to typedef a type
that is named 'long'.

It would make much more sense to use "__word" for reasons like that.
But I really don't think that works well in a x86 context.

Other ideas? Maybe "__wordsize" would be less associated with x86 16-bit words?

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

On 05/17/2012 03:56 PM, Linus Torvalds wrote:

__[su]native maybe?

        -hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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

On 05/17/2012 03:13 PM, H.J. Lu wrote:

Has anybody checked how this affects MIPS n32 userspace?

I think it totally breaks it.

In addition, 109a1f32 (sysinfo: Use explicit types in <linux/sysinfo.h>)
is probably bad.  I think it may need to be reverted, or somebody should
fix all the __kernel_{,u}long_t definitions for the ABI that may have
been broken by the change.

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

On 05/17/2012 04:11 PM, H. Peter Anvin wrote:

You should have asked for a 'solid basis'.

My basis is that the name '__kernel_ulong_t' implies, in my mind, that
it would have the width of a kernel unsigned long.

Really it should be called something like __abi_alternate_ulong_t.

After further reflection on this, you are probably right.

Sorry for raising the alarm (or would that be crying Wolf?).

Yes.

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

On 05/17/2012 04:25 PM, David Daney wrote:

The namespace __kernel_* doesn't mean "as used in the kernel" but rather
"exported by the kernel".  But yes, see also Linus' criticism.

        -hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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

On 05/17/2012 03:13 PM, H.J. Lu wrote:

This patch and the one before it seems to have another problem: we
currently define __BITS_PER_LONG as:

#ifdef __x86_64__
# define __BITS_PER_LONG 64
#else
# define __BITS_PER_LONG 32
#endif

.. which means __BITS_PER_LONG == 64 on x86-64.  This seems wrong.  The
result would seem to be that the padding members around __kernel_time_t
in struct shmid64_ds (not visible in patch 07/10 but existing in the
same structure) work by accident (I also wonder how the heck they're
currently supposed to work on bigendian architectures!!)

However, whereas struct shmid64_ds seems to work okay, this patch would
now seem to be wrong.

The sane thing would seem to be to change __BITS_PER_LONG to 32 on x32
and fix the padding hacks in struct shmid64_ds; H.J., would you agree?

        -hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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

On 05/17/2012 03:56 PM, Linus Torvalds wrote:

FWIW: "__abi_wordsize" to indicate that it is not really a property of
the machine itself, but rather the ABI in use.

David Daney

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

On Thu, May 17, 2012 at 4:51 PM, H. Peter Anvin <h...@zytor.com> wrote:

Ugh. That looks like a disaster.

The padding hacks that depend on __BITS_PER_LONG seem pretty damn broken anyway.

They only work if the kernel agrees with the value (which is against
the whole point of making __BITS_PER_LONG be about some user-level ABI
thing) or for little-endian machines.

IOW, all the __BITS_PER_LONG games look totally broken to me. I can't
see how they could possibly even be fixed.

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

On 05/17/2012 05:07 PM, Linus Torvalds wrote:

Well, on existing compat (e.g. i386) __BITS_PER_LONG is definitely not
the same as kernel.  And yes, I don't see how the heck this was ever
correct on bigendian machines or even for compat in any form (if the
kernel tries to interpret the extra bits and user space didn't
initialize them we're lost.)

The "logical" thing to do here seems to just use __s64, but I have no
idea if that would suddenly break bigendian architectures...

David, Ralf, do you have any idea what e.g. MIPS does here?

        -hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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

On 05/17/2012 05:19 PM, Mike Frysinger wrote:

Link please?

        -hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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