include/linux/kstrtox.h | 9 +++---- init/initramfs.c | 60 ++++++++++++++++++++++------------------- lib/vsprintf.c | 7 ----- 3 files changed, 36 insertions(+), 40 deletions(-)
The series that introduced simple_strntoul() had passed into kernel without proper review and hence reinvented a wheel that's not needed. Here is the refactoring to show that. This is assumed to go via PRINTK tree. I have tested this on x86, but I believe the same result will be on big-endian CPUs (I deduced that from how strtox() works). Andy Shevchenko (4): initramfs: Sort headers alphabetically initramfs: Refactor to use hex2bin() instead of custom approach vsprintf: Revert "add simple_strntoul" kstrtox: Drop extern keyword in the simple_strtox() declarations include/linux/kstrtox.h | 9 +++---- init/initramfs.c | 60 ++++++++++++++++++++++------------------- lib/vsprintf.c | 7 ----- 3 files changed, 36 insertions(+), 40 deletions(-) -- 2.50.1
> Here is the refactoring to show that. This is assumed to go via PRINTK > tree. No, initramfs is maintained by the VFS and we already carry other patches. If you want the kstrtox changes to go another route then I will take the first two changes in a stable branch that can be merged. > > I have tested this on x86, but I believe the same result will be > on big-endian CPUs (I deduced that from how strtox() works). Did you rerun the kunit tests the original change was part of or did you do some custom testing?
On Tue, Jan 20, 2026 at 12:20:41PM +0100, Christian Brauner wrote: > > Here is the refactoring to show that. This is assumed to go via PRINTK > > tree. > > No, initramfs is maintained by the VFS and we already carry other patches. If this applies cleanly, take them through it, I will be glad, thanks! > If you want the kstrtox changes to go another route then I will take the > first two changes in a stable branch that can be merged. I am fine with this route as long as the custom approach is gone. > > I have tested this on x86, but I believe the same result will be > > on big-endian CPUs (I deduced that from how strtox() works). > > Did you rerun the kunit tests the original change was part of or did you > do some custom testing? I'm not sure I understand the point. There were no test cases added for simple_strntoul() AFAICS. Did I miss anything? (If I didn't that is the second point on why the patches didn't get enough time for review and not every stakeholder seen them, usually we require the test cases for new APIs.) -- With Best Regards, Andy Shevchenko
On Tue, Jan 20, 2026 at 02:46:54PM +0200, Andy Shevchenko wrote: > On Tue, Jan 20, 2026 at 12:20:41PM +0100, Christian Brauner wrote: > > > Here is the refactoring to show that. This is assumed to go via PRINTK > > > tree. > > > > No, initramfs is maintained by the VFS and we already carry other patches. > > If this applies cleanly, take them through it, I will be glad, thanks! > > > If you want the kstrtox changes to go another route then I will take the > > first two changes in a stable branch that can be merged. > > I am fine with this route as long as the custom approach is gone. > > > > I have tested this on x86, but I believe the same result will be > > > on big-endian CPUs (I deduced that from how strtox() works). > > > > Did you rerun the kunit tests the original change was part of or did you > > do some custom testing? > > I'm not sure I understand the point. There were no test cases added for > simple_strntoul() AFAICS. Did I miss anything? > > (If I didn't that is the second point on why the patches didn't get enough > time for review and not every stakeholder seen them, usually we require > the test cases for new APIs.) Sorry, I meant the kunit tests that do test the initramfs unpacking.
On Fri, Jan 23, 2026 at 01:22:44PM +0100, Christian Brauner wrote: > On Tue, Jan 20, 2026 at 02:46:54PM +0200, Andy Shevchenko wrote: > > On Tue, Jan 20, 2026 at 12:20:41PM +0100, Christian Brauner wrote: > > > > Here is the refactoring to show that. This is assumed to go via PRINTK > > > > tree. > > > No, initramfs is maintained by the VFS and we already carry other patches. > > > > If this applies cleanly, take them through it, I will be glad, thanks! > > > > > If you want the kstrtox changes to go another route then I will take the > > > first two changes in a stable branch that can be merged. > > > > I am fine with this route as long as the custom approach is gone. > > > > > > I have tested this on x86, but I believe the same result will be > > > > on big-endian CPUs (I deduced that from how strtox() works). > > > > > > Did you rerun the kunit tests the original change was part of or did you > > > do some custom testing? > > > > I'm not sure I understand the point. There were no test cases added for > > simple_strntoul() AFAICS. Did I miss anything? > > > > (If I didn't that is the second point on why the patches didn't get enough > > time for review and not every stakeholder seen them, usually we require > > the test cases for new APIs.) > > Sorry, I meant the kunit tests that do test the initramfs unpacking. Nope, I run on the real HW with real initramfs and I saw the difference when code was under development (not working). The version I sent works good. But noted, next time I will run also above mentioned test cases, thanks for pointing that out. -- With Best Regards, Andy Shevchenko
© 2016 - 2026 Red Hat, Inc.