Message ID | 20170518062705.25902-4-hch@lst.de (mailing list archive) |
---|---|
State | Not Applicable |
Headers | show |
On Thu, 2017-05-18 at 08:26 +0200, Christoph Hellwig wrote: > We don't use uuid_be and the UUID_BE constants in any uapi headers, so make > them private to the kernel. On the assumption that no user program uses them? Is that a safe assumption? > diff --git a/include/uapi/linux/uuid.h b/include/uapi/linux/uuid.h > index 3738e5fb6a4d..0099756c4bac 100644 > --- a/include/uapi/linux/uuid.h > +++ b/include/uapi/linux/uuid.h > @@ -24,10 +24,6 @@ typedef struct { > __u8 b[16]; > } uuid_le; > > -typedef struct { > - __u8 b[16]; > -} uuid_be; > - > #define UUID_LE(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7) \ > ((uuid_le) \ > {{ (a) & 0xff, ((a) >> 8) & 0xff, ((a) >> 16) & 0xff, ((a) >> 24) & 0xff, \ > @@ -35,20 +31,8 @@ typedef struct { > (c) & 0xff, ((c) >> 8) & 0xff, \ > (d0), (d1), (d2), (d3), (d4), (d5), (d6), (d7) }}) > > -#define UUID_BE(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7) \ > -((uuid_be) \ > -{{ ((a) >> 24) & 0xff, ((a) >> 16) & 0xff, ((a) >> 8) & 0xff, (a) & 0xff, \ > - ((b) >> 8) & 0xff, (b) & 0xff, \ > - ((c) >> 8) & 0xff, (c) & 0xff, \ > - (d0), (d1), (d2), (d3), (d4), (d5), (d6), (d7) }}) > - > #define NULL_UUID_LE \ > UUID_LE(0x00000000, 0x0000, 0x0000, 0x00, 0x00, 0x00, 0x00, \ > 0x00, 0x00, 0x00, 0x00) > > -#define NULL_UUID_BE \ > - UUID_BE(0x00000000, 0x0000, 0x0000, 0x00, 0x00, 0x00, 0x00, \ > - 0x00, 0x00, 0x00, 0x00) > - > - > #endif /* _UAPI_LINUX_UUID_H_ */
On Thu, May 18, 2017 at 12:12:45AM -0700, Joe Perches wrote: > On Thu, 2017-05-18 at 08:26 +0200, Christoph Hellwig wrote: > > We don't use uuid_be and the UUID_BE constants in any uapi headers, so make > > them private to the kernel. > > On the assumption that no user program uses them? > Is that a safe assumption? It's not a userspace ABI, so by defintion it does not break an existing user program. If someone was using it they should be using uuid_t from libuuid instead, as that gives them the routines to deal with it.
Christoph Hellwig <hch@lst.de> wrote: > It's not a userspace ABI, so by defintion it does not break an > existing user program. That's an invalid assumption. It is a de facto userspace ABI as it has been exposed in /usr/include/linux/uuid.h for some time. > If someone was using it they should be using uuid_t from libuuid instead, as > that gives them the routines to deal with it. Yes, they should - but that doesn't mean they do. David
On Fri, May 19, 2017 at 11:58:41AM +0100, David Howells wrote: > Christoph Hellwig <hch@lst.de> wrote: > > > It's not a userspace ABI, so by defintion it does not break an > > existing user program. > > That's an invalid assumption. It is a de facto userspace ABI as it has been > exposed in /usr/include/linux/uuid.h for some time. It is never passed through any kernel interface, which by defintion does not make it an ABI. And even if it was we are not going to change the ABI for a uuid_t ever. We're just changing the internal name, and stop exposing the old name which was never used in an ABI to userspace.
diff --git a/include/linux/uuid.h b/include/linux/uuid.h index 4dff73a89758..de3aea206562 100644 --- a/include/linux/uuid.h +++ b/include/linux/uuid.h @@ -18,6 +18,21 @@ #include <uapi/linux/uuid.h> +typedef struct { + __u8 b[16]; +} uuid_be; + +#define UUID_BE(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7) \ +((uuid_be) \ +{{ ((a) >> 24) & 0xff, ((a) >> 16) & 0xff, ((a) >> 8) & 0xff, (a) & 0xff, \ + ((b) >> 8) & 0xff, (b) & 0xff, \ + ((c) >> 8) & 0xff, (c) & 0xff, \ + (d0), (d1), (d2), (d3), (d4), (d5), (d6), (d7) }}) + +#define NULL_UUID_BE \ + UUID_BE(0x00000000, 0x0000, 0x0000, 0x00, 0x00, 0x00, 0x00, \ + 0x00, 0x00, 0x00, 0x00) + /* * V1 (time-based) UUID definition [RFC 4122]. * - the timestamp is a 60-bit value, split 32/16/12, and goes in 100ns diff --git a/include/uapi/linux/uuid.h b/include/uapi/linux/uuid.h index 3738e5fb6a4d..0099756c4bac 100644 --- a/include/uapi/linux/uuid.h +++ b/include/uapi/linux/uuid.h @@ -24,10 +24,6 @@ typedef struct { __u8 b[16]; } uuid_le; -typedef struct { - __u8 b[16]; -} uuid_be; - #define UUID_LE(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7) \ ((uuid_le) \ {{ (a) & 0xff, ((a) >> 8) & 0xff, ((a) >> 16) & 0xff, ((a) >> 24) & 0xff, \ @@ -35,20 +31,8 @@ typedef struct { (c) & 0xff, ((c) >> 8) & 0xff, \ (d0), (d1), (d2), (d3), (d4), (d5), (d6), (d7) }}) -#define UUID_BE(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7) \ -((uuid_be) \ -{{ ((a) >> 24) & 0xff, ((a) >> 16) & 0xff, ((a) >> 8) & 0xff, (a) & 0xff, \ - ((b) >> 8) & 0xff, (b) & 0xff, \ - ((c) >> 8) & 0xff, (c) & 0xff, \ - (d0), (d1), (d2), (d3), (d4), (d5), (d6), (d7) }}) - #define NULL_UUID_LE \ UUID_LE(0x00000000, 0x0000, 0x0000, 0x00, 0x00, 0x00, 0x00, \ 0x00, 0x00, 0x00, 0x00) -#define NULL_UUID_BE \ - UUID_BE(0x00000000, 0x0000, 0x0000, 0x00, 0x00, 0x00, 0x00, \ - 0x00, 0x00, 0x00, 0x00) - - #endif /* _UAPI_LINUX_UUID_H_ */
We don't use uuid_be and the UUID_BE constants in any uapi headers, so make them private to the kernel. Signed-off-by: Christoph Hellwig <hch@lst.de> --- include/linux/uuid.h | 15 +++++++++++++++ include/uapi/linux/uuid.h | 16 ---------------- 2 files changed, 15 insertions(+), 16 deletions(-)