On Thu, 2019-10-31 at 22:59 +0000, Dimitri John Ledkov wrote:> linux/loop.h header is exported by linux, for userspace to > consume. This would prevent issues with struct sizes > incompatibilities.[...] The structure definitions can't change in future, so I don't think that's a real issue after the previous patch. But I agree that we should prefer using the kernel's UAPI headers wherever possible. Ben. -- Ben Hutchings Reality is just a crutch for people who can't handle science fiction. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: <https://lists.zytor.com/archives/klibc/attachments/20191101/da98e5bb/attachment.sig>
Dimitri John Ledkov
2019-Nov-01 14:40 UTC
[klibc] [PATCH 2/2] loop: switch to linux/loop.h
On Fri, 1 Nov 2019 at 14:36, Ben Hutchings <ben at decadent.org.uk> wrote:> > On Thu, 2019-10-31 at 22:59 +0000, Dimitri John Ledkov wrote: > > linux/loop.h header is exported by linux, for userspace to > > consume. This would prevent issues with struct sizes > > incompatibilities. > [...] > > The structure definitions can't change in future, so I don't think > that's a real issue after the previous patch. But I agree that we > should prefer using the kernel's UAPI headers wherever possible.Correct, this was my thinking too. But for example, I did not check how far back UAPI loop.h was provided, and whether users have it available at klibc build time. And kind of wanted to show the bug with current loop.h, such that it's available for cherrypicking & backports. But indeed, either of the two patches fixes the identified problem. One is minimal, and this one is slightly more invasive. -- Regards, Dimitri.
On Fri, 1 Nov 2019 at 14:40:24, Dimitri John Ledkov wrote:> > On Fri, 1 Nov 2019 at 14:36, Ben Hutchings <ben at decadent.org.uk> wrote: > > > The structure definitions can't change in future, so I don't think > > that's a real issue after the previous patch. But I agree that we > > should prefer using the kernel's UAPI headers wherever possible. > > But for example, I did not check how far back UAPI loop.h was > provided, and whether users have it available at klibc build time. And > kind of wanted to show the bug with current loop.h, such that it's > available for cherrypicking & backports.I checked as far back as 3.2 (does anyone other than RHEL care about kernels older than that and, frankly, do we care to support them?), and linux/loop.h is exported there and is certainly more correct than the version shipped in klibc. While I originally encouraged you to submit both patches, I think I'm now firmly in the "scorched earth" camp, where we should just trust that the kernel has it right, and stop trying to duplicate it. So, unless there are strong objections, please take this version of the patch. ... Adam