* Linus Torvalds:
> On Mon, Jun 17, 2019 at 11:19 AM Florian Weimer wrote:
>> >
>> > Unlike the "val[]" thing, I don't think anybody is supposed to access
>> > those fields directly.
>>
>> Well, glibc already calls it __val …
>
> Hmm. If user space already doesn't see the "val[]" array anyway, I
On Mon, Jun 17, 2019 at 11:19 AM Florian Weimer wrote:
> >
> > Unlike the "val[]" thing, I don't think anybody is supposed to access
> > those fields directly.
>
> Well, glibc already calls it __val …
Hmm. If user space already doesn't see the "val[]" array anyway, I
guess we could just do that
* Linus Torvalds:
> On Mon, Jun 17, 2019 at 11:03 AM Florian Weimer wrote:
>>
>> There's also __kernel_fd_set in . I may have
>> lumped this up with , but it has the same problem.
>
> Hmm.
>
> That one we might be able to just fix by renaming "fds_bits" to "__fds_bits".
>
> Unlike the "val[]"
On Mon, Jun 17, 2019 at 11:13 AM Linus Torvalds
wrote:
>
> That one we might be able to just fix by renaming "fds_bits" to "__fds_bits".
That said, moving it to another file might be the better option anyway.
I think fd_set and friends are now supposed to be in
anyway, and the "it was in " is
On Mon, Jun 17, 2019 at 11:03 AM Florian Weimer wrote:
>
> There's also __kernel_fd_set in . I may have
> lumped this up with , but it has the same problem.
Hmm.
That one we might be able to just fix by renaming "fds_bits" to "__fds_bits".
Unlike the "val[]" thing, I don't think anybody is
* Linus Torvalds:
>> A different approach would rename to something more
>> basic, exclude the two structs, and move all internal #includes which do
>> need the structs to the new header.
>
> In fact, I wouldn't even rename at all, I'd just make
> sure it's namespace-clean.
>
> I _think_ the
On Mon, Jun 17, 2019 at 4:45 AM Florian Weimer wrote:
>
> I wanted to introduce a new header, , and include
> it where the definition of __kernel_long_t is needed, something like
> this (incomplete, untested):
So this doesn't look interesting to me: __kernel_long_t is neither
interesting as a
* Linus Torvalds:
> On Fri, Jun 7, 2019 at 11:43 AM Florian Weimer wrote:
>>
>> 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
>>
On Fri, Jun 7, 2019 at 11:43 AM Florian Weimer wrote:
>
> 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
* 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
On Thu, Jun 6, 2019 at 9:28 PM Florian Weimer wrote:
>
> This regression fix still hasn't been merged into Linus' tree. What is
> going on here?
.. it was never sent to me.
That said, now that I see the patch, I wonder why we'd have that
#ifdef __KERNEL__ in here:
typedef struct {
+#ifdef
* Joseph Myers:
> What happened with this patch (posted 19 March)? I found today that we
> can't use Linux 5.1 headers in glibc testing because the namespace issues
> are still present in the headers as of the release.
This regression fix still hasn't been merged into Linus' tree. What is
12 matches
Mail list logo
