[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <871s05fd8o.fsf@oldenburg2.str.redhat.com>
Date: Fri, 07 Jun 2019 20:43:03 +0200
From: Florian Weimer <fweimer@...hat.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Joseph Myers <joseph@...esourcery.com>,
Arnd Bergmann <arnd@...db.de>,
Linux API <linux-api@...r.kernel.org>,
linux-arch <linux-arch@...r.kernel.org>,
Netdev <netdev@...r.kernel.org>,
Laura Abbott <labbott@...hat.com>,
Paul Burton <pburton@...ecomp.com>,
Deepa Dinamani <deepa.kernel@...il.com>,
Linux List Kernel Mailing <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] uapi: avoid namespace conflict in linux/posix_types.h
* Linus Torvalds:
> If we're changing kernel header files, it's easy enough to change the
> kernel users. I'd be more worried about user space that *uses* that
> thing, and currently accesses 'val[]' by name.
>
> So the patch looks a bit odd to me. How are people supposed to use
> fsid_t if they can't look at it?
The problem is that the header was previously not used pervasively in
userspace headers. See commit a623a7a1a5670c25a16881f5078072d272d96b71
("y2038: fix socket.h header inclusion"). Very little code needed it
before.
On the glibc side, we nowadays deal with this by splitting headers
further. (We used to suppress definitions with macros, but that tended
to become convoluted.) In this case, moving the definition of
__kernel_long_t to its own header, so that
include/uapi/asm-generic/socket.h can include that should fix it.
> So now that I _do_ see the patch, there's no way I'll apply it.
Fair enough.
Thanks,
Florian
Powered by blists - more mailing lists