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
On Mon, 2019-11-04 at 17:44 +0000, Adam Conrad wrote:> 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?),klibc generally doessn't attempt to provide any kernel backward compatibility. So whatever works with the latest stable kernel is fine. (With my Debian hat on, I sometimes have to restore old kernel compatibility.)> 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.Let's just do that then. Ben. -- Ben Hutchings If God had intended Man to program, we'd have been born with serial I/O ports. -------------- 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/20191105/f89ca0cf/attachment.sig>
On Tue, 2019-11-05 at 00:20 +0000, Ben Hutchings wrote:> On Mon, 2019-11-04 at 17:44 +0000, Adam Conrad wrote: > > 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?), > > klibc generally doessn't attempt to provide any kernel backward > compatibility. So whatever works with the latest stable kernel is > fine.[?] ? which means we also don't even need the fallbacks from LOOP_{GET,SET}_STATUS to the old versions of those ioctls. Ben. -- Ben Hutchings If God had intended Man to program, we'd have been born with serial I/O ports. -------------- 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/20191105/3dccd601/attachment.sig>