[PATCH 0/5] Patches used to build mkroot.

[PATCH 0/5] Patches used to build mkroot.

[Rob Landley]

The ~300 line bash script in toybox that builds bootable Linux systems
for a dozen-ish targets can use a vanilla kernel, but the binaries I
ship are built from a kernel with these patches:

https://github.com/landley/toybox/blob/master/scripts/mkroot.sh
https://landley.net/toybox/downloads/binaries/mkroot/0.8.9/

I've posted each patch to the list already, but here they are together
and updated for 6.2:

1) let LLVM build normally without telling Linux on the command line
This way I can mix CROSS_COMPILE=$ARCH-unknown-linux-cross- without
having to care that some are llvm and some are gcc.

2) don't require an extra dependency to build x86-64 no other target needs.

3) Make CONFIG_DEVTMPFS_MOUNT work in initramfs. That way having
the kernel build archive up a directory into a cpio.gz as a normal
user doesn't leave me without a /dev/console and thus init running
with stdin/stderr/stdout closed.

4) Replace the only user of bc with c. (Another package dependency
with only one user.)

5) Fix rootfstype=tmpfs in initramfs. (A thinko I made in 2013 which
nobody else has bothered to fix for a decade now.)

[PATCH 1/5] try generic compiler name "cc" before falling back to "gcc".

[Rob Landley]

Distros like debian install the generic "cc" name for both gcc and clang,
and the plumbing already does CC_VERSION_TEXT to include Makefile.clang.

Previously: https://lkml.iu.edu/hypermail/linux/kernel/2202.0/01505.html
Signed-off-by: Rob Landley <rob@landley.net>
---
 Makefile | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 3f6628780eb2..0ac57ae3b45f 100644
--- a/Makefile
+++ b/Makefile
@@ -456,7 +456,7 @@ endif
 HOSTCC	= $(LLVM_PREFIX)clang$(LLVM_SUFFIX)
 HOSTCXX	= $(LLVM_PREFIX)clang++$(LLVM_SUFFIX)
 else
-HOSTCC	= gcc
+HOSTCC	:= $(shell cc --version >/dev/null 2>&1 && echo cc || echo gcc)
 HOSTCXX	= g++
 endif
 HOSTRUSTC = rustc
@@ -503,7 +503,8 @@ OBJDUMP		= $(LLVM_PREFIX)llvm-objdump$(LLVM_SUFFIX)
 READELF		= $(LLVM_PREFIX)llvm-readelf$(LLVM_SUFFIX)
 STRIP		= $(LLVM_PREFIX)llvm-strip$(LLVM_SUFFIX)
 else
-CC		= $(CROSS_COMPILE)gcc
+CC		:= $(CROSS_COMPILE)$(shell $(CROSS_COMPILE)cc --version \
+			>/dev/null 2>&1 && echo cc || echo gcc)
 LD		= $(CROSS_COMPILE)ld
 AR		= $(CROSS_COMPILE)ar
 NM		= $(CROSS_COMPILE)nm

Re: [PATCH 1/5] try generic compiler name "cc" before falling back to "gcc".

[Masahiro Yamada]

On Wed, Feb 22, 2023 at 5:41 AM Rob Landley <rob@landley.net> wrote:
>
> Distros like debian install the generic "cc" name for both gcc and clang,
> and the plumbing already does CC_VERSION_TEXT to include Makefile.clang.
>
> Previously: https://lkml.iu.edu/hypermail/linux/kernel/2202.0/01505.html
> Signed-off-by: Rob Landley <rob@landley.net>
> ---
>  Makefile | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 3f6628780eb2..0ac57ae3b45f 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -456,7 +456,7 @@ endif
>  HOSTCC = $(LLVM_PREFIX)clang$(LLVM_SUFFIX)
>  HOSTCXX        = $(LLVM_PREFIX)clang++$(LLVM_SUFFIX)
>  else
> -HOSTCC = gcc
> +HOSTCC := $(shell cc --version >/dev/null 2>&1 && echo cc || echo gcc)



'cc' only makes sense for the host compiler,
which is configured by 'update-alternative'.

I tried it before, but LLVM folks preferred
using $(LLVM) to choose clang/gcc.






>  HOSTCXX        = g++
>  endif
>  HOSTRUSTC = rustc
> @@ -503,7 +503,8 @@ OBJDUMP             = $(LLVM_PREFIX)llvm-objdump$(LLVM_SUFFIX)
>  READELF                = $(LLVM_PREFIX)llvm-readelf$(LLVM_SUFFIX)
>  STRIP          = $(LLVM_PREFIX)llvm-strip$(LLVM_SUFFIX)
>  else
> -CC             = $(CROSS_COMPILE)gcc
> +CC             := $(CROSS_COMPILE)$(shell $(CROSS_COMPILE)cc --version \
> +                       >/dev/null 2>&1 && echo cc || echo gcc)

This hunk sets up GCC/binutils.
So, cc does not make sense.  NACK.






>  LD             = $(CROSS_COMPILE)ld
>  AR             = $(CROSS_COMPILE)ar
>  NM             = $(CROSS_COMPILE)nm



-- 
Best Regards
Masahiro Yamada

Re: [PATCH 1/5] try generic compiler name "cc" before falling back to "gcc".

[Rob Landley]

On 2/22/23 23:31, Masahiro Yamada wrote:
> On Wed, Feb 22, 2023 at 5:41 AM Rob Landley <rob@landley.net> wrote:
>>
>> Distros like debian install the generic "cc" name for both gcc and clang,
>> and the plumbing already does CC_VERSION_TEXT to include Makefile.clang.
>>
>> Previously: https://lkml.iu.edu/hypermail/linux/kernel/2202.0/01505.html
>> Signed-off-by: Rob Landley <rob@landley.net>
>> ---
>>  Makefile | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/Makefile b/Makefile
>> index 3f6628780eb2..0ac57ae3b45f 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -456,7 +456,7 @@ endif
>>  HOSTCC = $(LLVM_PREFIX)clang$(LLVM_SUFFIX)
>>  HOSTCXX        = $(LLVM_PREFIX)clang++$(LLVM_SUFFIX)
>>  else
>> -HOSTCC = gcc
>> +HOSTCC := $(shell cc --version >/dev/null 2>&1 && echo cc || echo gcc)
> 
> 'cc' only makes sense for the host compiler,

It was the generic posix name for "C compiler" until posix decided to put an
expiration date in the command name, which seems as widely honored as the
tar->pax switch or the removal of cpio.

The name "gcc" was like "gmake" and "gawk". (On macos homebrew there's "gsed".)

> which is configured by 'update-alternative'.

Hexagon only has llvm support, not gcc, so I had to add an llvm cross compiler
to my cross compiler set, prefixed hexagon-unknown-linux-musl-*, but the linux
kernel wants to call it as hexagon-unknown-linux-musl-gcc.

The kernel builds find with a "gcc" symlink to clang, but there _is_ a generic
name, which is widely installed.

> I tried it before, but LLVM folks preferred
> using $(LLVM) to choose clang/gcc.

So if we want generic behavior without having to specify, we should create a
"gcc" symlink to clang?

>>  HOSTCXX        = g++
>>  endif
>>  HOSTRUSTC = rustc
>> @@ -503,7 +503,8 @@ OBJDUMP             = $(LLVM_PREFIX)llvm-objdump$(LLVM_SUFFIX)
>>  READELF                = $(LLVM_PREFIX)llvm-readelf$(LLVM_SUFFIX)
>>  STRIP          = $(LLVM_PREFIX)llvm-strip$(LLVM_SUFFIX)
>>  else
>> -CC             = $(CROSS_COMPILE)gcc
>> +CC             := $(CROSS_COMPILE)$(shell $(CROSS_COMPILE)cc --version \
>> +                       >/dev/null 2>&1 && echo cc || echo gcc)
> 
> This hunk sets up GCC/binutils.

This is the codepath that's taken when you don't explicitly specify "LLVM=1".
The test there is falling back to (appropriately prefixed) gcc when it can't
find a working (appropriately prefixed) cc.

> So, cc does not make sense.  NACK.

Do you explicitly specify the "gold" linker vs the previous gnu one vs
lld.llvm.org on the kernel build command line?

Rob

Re: [PATCH 1/5] try generic compiler name "cc" before falling back to "gcc".

[Masahiro Yamada]

On Thu, Feb 23, 2023 at 10:36 PM Rob Landley <rob@landley.net> wrote:
>
> On 2/22/23 23:31, Masahiro Yamada wrote:
> > On Wed, Feb 22, 2023 at 5:41 AM Rob Landley <rob@landley.net> wrote:
> >>
> >> Distros like debian install the generic "cc" name for both gcc and clang,
> >> and the plumbing already does CC_VERSION_TEXT to include Makefile.clang.
> >>
> >> Previously: https://lkml.iu.edu/hypermail/linux/kernel/2202.0/01505.html
> >> Signed-off-by: Rob Landley <rob@landley.net>
> >> ---
> >>  Makefile | 5 +++--
> >>  1 file changed, 3 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/Makefile b/Makefile
> >> index 3f6628780eb2..0ac57ae3b45f 100644
> >> --- a/Makefile
> >> +++ b/Makefile
> >> @@ -456,7 +456,7 @@ endif
> >>  HOSTCC = $(LLVM_PREFIX)clang$(LLVM_SUFFIX)
> >>  HOSTCXX        = $(LLVM_PREFIX)clang++$(LLVM_SUFFIX)
> >>  else
> >> -HOSTCC = gcc
> >> +HOSTCC := $(shell cc --version >/dev/null 2>&1 && echo cc || echo gcc)
> >
> > 'cc' only makes sense for the host compiler,
>
> It was the generic posix name for "C compiler" until posix decided to put an
> expiration date in the command name, which seems as widely honored as the
> tar->pax switch or the removal of cpio.
>
> The name "gcc" was like "gmake" and "gawk". (On macos homebrew there's "gsed".)
>
> > which is configured by 'update-alternative'.
>
> Hexagon only has llvm support, not gcc, so I had to add an llvm cross compiler
> to my cross compiler set, prefixed hexagon-unknown-linux-musl-*, but the linux
> kernel wants to call it as hexagon-unknown-linux-musl-gcc.
>
> The kernel builds find with a "gcc" symlink to clang, but there _is_ a generic
> name, which is widely installed.



In the discussion in the past [1], we decided to
go with LLVM=1 switch rather than 'cc'.
We do not need both.

[1]: https://lkml.org/lkml/2020/3/28/494








>
> > I tried it before, but LLVM folks preferred
> > using $(LLVM) to choose clang/gcc.
>
> So if we want generic behavior without having to specify, we should create a
> "gcc" symlink to clang?


If you mean "without LLVM=1 or HOSTCC=clang specified",
I think the answer is yes.






>
> >>  HOSTCXX        = g++
> >>  endif
> >>  HOSTRUSTC = rustc
> >> @@ -503,7 +503,8 @@ OBJDUMP             = $(LLVM_PREFIX)llvm-objdump$(LLVM_SUFFIX)
> >>  READELF                = $(LLVM_PREFIX)llvm-readelf$(LLVM_SUFFIX)
> >>  STRIP          = $(LLVM_PREFIX)llvm-strip$(LLVM_SUFFIX)
> >>  else
> >> -CC             = $(CROSS_COMPILE)gcc
> >> +CC             := $(CROSS_COMPILE)$(shell $(CROSS_COMPILE)cc --version \
> >> +                       >/dev/null 2>&1 && echo cc || echo gcc)
> >
> > This hunk sets up GCC/binutils.
>
> This is the codepath that's taken when you don't explicitly specify "LLVM=1".
> The test there is falling back to (appropriately prefixed) gcc when it can't
> find a working (appropriately prefixed) cc.


Unless LLVM=1 is specified, the toolchain defaults to GCC/binutils,
there is no need for such additional complexity.




>
> > So, cc does not make sense.  NACK.
>
> Do you explicitly specify the "gold" linker vs the previous gnu one vs
> lld.llvm.org on the kernel build command line?


gold is unsupported.
See 75959d44f9dc8e44410667009724e4e238515502


Yes, to override only LD, LD=ld.lld should be given in the command line.





>
> Rob



-- 
Best Regards
Masahiro Yamada

[PATCH 2/5] X86-64 should not uniquely require a third ELF package to build.

[Rob Landley]

x86-64 is the only architecture that can't compile without an extra
ELF library installed on the host. (The kernel already has multiple ELF
parse implementations built-in, so requiring another one is questionable
at best.) You can switch it back on in menuconfig if you want to, this
just stops it being mandatory.

See https://lkml.iu.edu/hypermail/linux/kernel/2110.3/00402.html
and https://lkml.iu.edu/hypermail/linux/kernel/2110.3/00278.html

Signed-off-by: Rob Landley <rob@landley.net>
---
 arch/x86/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 3604074a878b..b63510d79baf 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -243,7 +243,6 @@ config X86
 	select HAVE_NOINSTR_HACK		if HAVE_OBJTOOL
 	select HAVE_NMI
 	select HAVE_NOINSTR_VALIDATION		if HAVE_OBJTOOL
-	select HAVE_OBJTOOL			if X86_64
 	select HAVE_OPTPROBES
 	select HAVE_PCSPKR_PLATFORM
 	select HAVE_PERF_EVENTS

Re: [PATCH 2/5] X86-64 should not uniquely require a third ELF package to build.

[Thomas Gleixner]

Rob!

On Tue, Feb 21 2023 at 14:56, Rob Landley wrote:

The subject line is not compliant to documentation. Please read and
follow Documentation/process/* especially submitting-patches.rst and
maintainer-tip.rst

> x86-64 is the only architecture that can't compile without an extra
> ELF library installed on the host. (The kernel already has multiple ELF
> parse implementations built-in, so requiring another one is questionable
> at best.)

How are ELF parsers in the kernel itself related to a build requirement
for a tool, which is part of the kernel build process?

Next time you ask for removal of perl, python or whatever the kernel
requires to build.

> You can switch it back on in menuconfig if you want to, this
> just stops it being mandatory.

How do you switch on CONFIG_HAVE_OBJTOOL in menuconfig?

config HAVE_OBJTOOL
        bool

There is no knob.

> See https://lkml.iu.edu/hypermail/linux/kernel/2110.3/00402.html
> and https://lkml.iu.edu/hypermail/linux/kernel/2110.3/00278.html

Please use https://lore.kernel.org/lkml/ links.

> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 3604074a878b..b63510d79baf 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -243,7 +243,6 @@ config X86
>  	select HAVE_NOINSTR_HACK		if HAVE_OBJTOOL
>  	select HAVE_NMI
>  	select HAVE_NOINSTR_VALIDATION		if HAVE_OBJTOOL
> -	select HAVE_OBJTOOL			if X86_64

This prevents runtime features, optimizations, mitigations and build
time validations rom being selected as you can see from your patch
context.

Just to be clear: objtool is mandatory for x86_64 builds.

git grep 'select HAVE_OBJTOOL' will tell you that your claim about
x86_64 being the only architecture is slightly wrong.

Thanks,

        tglx

Re: [PATCH 2/5] X86-64 should not uniquely require a third ELF package to build.

[Rob Landley]

On 2/21/23 17:12, Thomas Gleixner wrote:
> Rob!

Thomas!

> On Tue, Feb 21 2023 at 14:56, Rob Landley wrote:
> 
> The subject line is not compliant to documentation. Please read and
> follow Documentation/process/* especially submitting-patches.rst and
> maintainer-tip.rst

I've read them multiple times over the years, but I'm not good at remembering
extensive bureaucracy over long periods. Let's see...

Are you complaining it doesn't have "RESEND"? These apply to 6.2, not 6.1, and a
couple things got tweaked. What's the "RESEND" threshold?

Or is this a "subsystem:" prefix thing where I have to guess what subsystem the
top level makefile or mktimeconst fall under? Is "init" a subsystem?

$ grep -i subsystem MAINTAINERS  | wc
     85     286    2216
$ grep -i subsystem MAINTAINERS  | grep -i init
$

Apparently not. I would have thought get_maintainer.pl would emit this sort of
info if it's important, but I guess I'm remembering back when Linux had
hobbyists who worked on things that didn't require justifying the time on a
spreadsheet to their boss in a budget allocation meeting before modifying any
code...

>> x86-64 is the only architecture that can't compile without an extra
>> ELF library installed on the host. (The kernel already has multiple ELF
>> parse implementations built-in, so requiring another one is questionable
>> at best.)
> 
> How are ELF parsers in the kernel itself related to a build requirement
> for a tool, which is part of the kernel build process?

The project already has multiple instances of code that traverses ELF data
structures. A definition of "code reuse" that pulls in an additional build
dependency which the project was not already using is just "code use" without a
"re".

My response was "this doesn't need to be done at all, it's just being used for
an optional stack unwinder, and even if you _want_ a stack unwinder there are
multiple other implementations without this dependency".

They just tangled up the kconfig plubmbing so even when nothing uses it, it
still tries to build the tool it won't run. If I'd tried to FIX the tool,
factoring out existing ELF code so it could be built on the host and used at
build time might have made sense. But the thing it's being used to do is not a
thing I need on the systems I'm building.

> Next time you ask for removal of perl, python or whatever the kernel
> requires to build.

Kernel doesn't require python to build, my perl removal series got merged 10
years ago, and other people have sent follow-up perl removal patches since.

>> You can switch it back on in menuconfig if you want to, this
>> just stops it being mandatory.
> 
> How do you switch on CONFIG_HAVE_OBJTOOL in menuconfig?
> 
> config HAVE_OBJTOOL
>         bool
> 
> There is no knob.

Sigh, I traced through all this stuff at one point. It's been a few releases
since then (and the symbol got renamed), and it looks like it's developed some
more dependencies off of it in kernel/trace/Kconfig.

Alright, how about this:

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 3604074a878b..70923305d596 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -243,7 +243,8 @@ config X86
        select HAVE_NOINSTR_HACK                if HAVE_OBJTOOL
        select HAVE_NMI
        select HAVE_NOINSTR_VALIDATION          if HAVE_OBJTOOL
-       select HAVE_OBJTOOL                     if X86_64
+       select HAVE_OBJTOOL                     if X86_64 && \
+         $(success,echo "#include <gelf.h>" | $(HOSTCC) -xc -o /dev/null -c -)
        select HAVE_OPTPROBES
        select HAVE_PCSPKR_PLATFORM
        select HAVE_PERF_EVENTS

Actually TEST if the build environment has it, and set the symbol appropriately.

Would that with "test for optional build dependency" work? I'm aware people want
to use this plumbing for more thorough spectre/meltdown style mitigations, but
Linux has CONFIG_MULTIUSER which can remove support for non-root users. (I'm off
at the embedded end of things: we're weird.)

>> See https://lkml.iu.edu/hypermail/linux/kernel/2110.3/00402.html
>> and https://lkml.iu.edu/hypermail/linux/kernel/2110.3/00278.html
> 
> Please use https://lore.kernel.org/lkml/ links.

Yeah, check_patch.pl complained about that too. Google's getting unreliable
enough it's not always easy to map between them, but I'll put it on the todo
list for the 6.3 repost of the series...

>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index 3604074a878b..b63510d79baf 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -243,7 +243,6 @@ config X86
>>  	select HAVE_NOINSTR_HACK		if HAVE_OBJTOOL
>>  	select HAVE_NMI
>>  	select HAVE_NOINSTR_VALIDATION		if HAVE_OBJTOOL
>> -	select HAVE_OBJTOOL			if X86_64
> 
> This prevents runtime features, optimizations, mitigations and build
> time validations rom being selected as you can see from your patch
> context.
> 
> Just to be clear: objtool is mandatory for x86_64 builds.

Because without this patch it's forced on, yes. Works fine without it in my testing?

The llvm guys built a whole compiler to get away from GPLv3 and
https://sourceware.org/elfutils is GPLv3, which is not _my_ motivation for
trying to avoid it, but I can see it being "of interest". (If the goal is to
push people away from x86-64 faster...)

No other architecture I tested had this requirement. I admit I'm only building
arm, arm64, x86, x86-64, m68k, mips, ppc32, ppc64, s390x, and superh kernels at
the moment. I'm only doing a userspace version of hexagon because they didn't
have qemu-system-hexagon working last I poked Taylor Simpson so I'd have nothing
to test the kernel on. Musl-libc's xtensa support is not just an out of tree
fork but _very_stale_ (the one I have, anyway). Musl doesn't support
alpha/arc/csky/itanic/mips-looongarch/nios2/parisc/sparc yet. Microblaze
binaries segfault in the ELF _start code for some reason (I should track down
why). I'm halfway to a working cortex-m qemu config and need to get back to that
(qemu SHOULD have a decent board, there's like 5 options now). Building or1k is
on the todo list...

> git grep 'select HAVE_OBJTOOL' will tell you that your claim about
> x86_64 being the only architecture is slightly wrong.

There's two hits, and the other is PPC32, which was building fine for me without
this patch last I checked?

Ah, commit e52ec98c5ab1 from 3 months ago. So 6.1 built fine without it but 6.2
also requires... no, hang on, I test built 6.2 with this patch series more than
once, and my patches don't modify the arch/powerpc directory? I still have the
binaries:

$ ./run-qemu.sh
...
Kernel memory protection not selected by kernel config.
Run /init as init process
Type exit when done.
# cat /proc/version
Linux version 6.2.0 (landley@driftwood) (powerpc-linux-musl-cc (GCC) 9.4.0, GNU
ld (GNU Binutils) 2.33.1) #1 Tue Feb 21 14:07:21 CST 2023
# cat /proc/cpuinfo
processor	: 0
cpu		: 740/750
clock		: 266.000000MHz
revision	: 3.1 (pvr 0008 0301)
bogomips	: 33.20

timebase	: 16603616
platform	: PowerMac
model		: Power Macintosh
machine		: Power Macintosh
motherboard	: AAPL,PowerMac G3 MacRISC
detected as	: 49 (PowerMac G3 (Silk))
pmac flags	: 00000000
pmac-generation	: OldWorld
Memory		: 256 MB
# file /bin/toybox
/bin/toybox: ELF executable, 32-bit MSB ppc, static, stripped


That's 6.2, G3 was 7xx series which is 32 bit... Yup, powerpc 32 bit built and
ran fine without this. I haven't got libelf-dev installed on my laptop, so it
CAN'T have required it,the build would break if it tried...

Which other architecture build breaks for you without libelf-dev installed?

> Thanks,
> 
>         tglx

Rob

Re: [PATCH 2/5] X86-64 should not uniquely require a third ELF package to build.

[Thomas Gleixner]

Rob!

On Wed, Feb 22 2023 at 12:14, Rob Landley wrote:
> On 2/21/23 17:12, Thomas Gleixner wrote:
>> The subject line is not compliant to documentation. Please read and
>> follow Documentation/process/* especially submitting-patches.rst and
>> maintainer-tip.rst
>
> I've read them multiple times over the years, but I'm not good at remembering
> extensive bureaucracy over long periods. Let's see...
>
> Are you complaining it doesn't have "RESEND"? These apply to 6.2, not 6.1, and a
> couple things got tweaked. What's the "RESEND" threshold?
>
> Or is this a "subsystem:" prefix thing where I have to guess what subsystem the
> top level makefile or mktimeconst fall under? Is "init" a subsystem?
>
> $ grep -i subsystem MAINTAINERS  | wc
>      85     286    2216
> $ grep -i subsystem MAINTAINERS  | grep -i init
> $

What has a patch against arch/x86 to do with init? I gave you two files
which extensively describe what we ask people to do.

https://www.kernel.org/doc/html/latest/process/maintainer-tip.html#patch-subject

Do you need some more explicit links?

These rules have been set in place to make the maintainer work
scalable. If you ignore them, then you are wasting other peoples
time. The logical consequence is that those people will ignore you too.

> Apparently not. I would have thought get_maintainer.pl would emit this sort of
> info if it's important, but I guess I'm remembering back when Linux had
> hobbyists who worked on things that didn't require justifying the time on a
> spreadsheet to their boss in a budget allocation meeting before modifying any
> code...

Your unrelated and non-sensical rants are not getting you anywhere.

>>> x86-64 is the only architecture that can't compile without an extra
>>> ELF library installed on the host. (The kernel already has multiple ELF
>>> parse implementations built-in, so requiring another one is questionable
>>> at best.)
>> 
>> How are ELF parsers in the kernel itself related to a build requirement
>> for a tool, which is part of the kernel build process?
>
> The project already has multiple instances of code that traverses ELF data
> structures. A definition of "code reuse" that pulls in an additional build
> dependency which the project was not already using is just "code use" without a
> "re".

Feel free to send patches against objtool to make use of those multiple
instances, which you gracefully omit to name.

> My response was "this doesn't need to be done at all, it's just being used for
> an optional stack unwinder, and even if you _want_ a stack unwinder there are
> multiple other implementations without this dependency".

Care to figure out what objtool really does and why it is required to
enable certain features? You might not care, but most people do for very
good reasons.

>> Just to be clear: objtool is mandatory for x86_64 builds.
>
> Because without this patch it's forced on, yes. Works fine without it
> in my testing?

Works for me does not cut it and you know that.

>> git grep 'select HAVE_OBJTOOL' will tell you that your claim about
>> x86_64 being the only architecture is slightly wrong.
>
> There's two hits, and the other is PPC32, which was building fine for me without
> this patch last I checked?

Select the right options on PPC32 or PPC64 and it requires objtool.

Just accept it. Your patch _is_ broken and it's not my problem to come
up with a solution which causes regressions for people who care and
depend on the features. It's just more work than removing a single line
in a Kconfig file and claiming that uncomprehensible word salad
qualifies as change log.

Please stop this right here and come back when you have something which
is worth to look at. I gave you enough pointers by now and I'm not going
to waste another second of my time on reading your rants.

Thanks,

        tglx

[PATCH 3/5] Wire up CONFIG_DEVTMPFS_MOUNT to initramfs.

[Rob Landley]

The kernel has had CONFIG_DEVTMPFS_MOUNT for years, but it only applied to
fallback ROOT= not initramfs/initmpfs. As long as the config option exists,
it might as well work.

I use this for board bringup: populating a chdir and calling cpio as a
normal user often leaves /dev empty (because mknod requires root access),
meaning no /dev/console for init/main.c to open, meaning init runs without
stdin/stdout/stderr and has to mount devtmpfs and redirect the filehandles
blind with no error output if something goes wrong.

Signed-off-by: Rob Landley <rob@landley.net>
Previously: https://lkml.org/lkml/2017/9/13/651
---
 init/main.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/init/main.c b/init/main.c
index e1c3911d7c70..eca7ba2c2764 100644
--- a/init/main.c
+++ b/init/main.c
@@ -1636,7 +1636,6 @@ static noinline void __init kernel_init_freeable(void)
 	kunit_run_all_tests();
 
 	wait_for_initramfs();
-	console_on_rootfs();
 
 	/*
 	 * check if there is an early userspace init.  If yes, let it do all
@@ -1645,7 +1644,11 @@ static noinline void __init kernel_init_freeable(void)
 	if (init_eaccess(ramdisk_execute_command) != 0) {
 		ramdisk_execute_command = NULL;
 		prepare_namespace();
+	} else if (IS_ENABLED(CONFIG_DEVTMPFS_MOUNT)) {
+		init_mkdir("/dev", 0755);
+		devtmpfs_mount();
 	}
+	console_on_rootfs();
 
 	/*
 	 * Ok, we have completed the initial bootup, and

[PATCH 4/5] Replace timeconst.bc with mktimeconst.c

[Rob Landley]

Update of my decade-old patch replacing timeconst.pl with mktimeconst.c,
still removing the only user of "bc" from the build.

All that's changed since the 2015 version at:
https://github.com/landley/aboriginal/blob/master/sources/patches/linux-noperl-timeconst.patch

Is one extra iteration of the loop for nanoseconds and different
makefile plumbing calling it. In theory this could calculate the values
at runtime in a small _init function and eliminate the header or even
allow HZ to change at runtime.

See https://lkml.iu.edu/hypermail/linux/kernel/2211.0/02589.html

Signed-off-by: Rob Landley <rob@landley.net>
---
 Kbuild                    |   7 ++-
 kernel/time/mktimeconst.c | 111 ++++++++++++++++++++++++++++++++++++
 kernel/time/timeconst.bc  | 117 --------------------------------------
 3 files changed, 116 insertions(+), 119 deletions(-)
 create mode 100644 kernel/time/mktimeconst.c
 delete mode 100644 kernel/time/timeconst.bc

diff --git a/Kbuild b/Kbuild
index 464b34a08f51..8c12f6ef58c6 100644
--- a/Kbuild
+++ b/Kbuild
@@ -18,9 +18,12 @@ $(bounds-file): kernel/bounds.s FORCE
 
 timeconst-file := include/generated/timeconst.h
 
-filechk_gentimeconst = echo $(CONFIG_HZ) | bc -q $<
+hostprogs += mktimeconst
+mktimeconst-objs = kernel/time/mktimeconst.o
 
-$(timeconst-file): kernel/time/timeconst.bc FORCE
+filechk_gentimeconst = $(obj)/mktimeconst $(CONFIG_HZ) -
+
+$(timeconst-file): $(obj)/mktimeconst FORCE
 	$(call filechk,gentimeconst)
 
 # Generate asm-offsets.h
diff --git a/kernel/time/mktimeconst.c b/kernel/time/mktimeconst.c
new file mode 100644
index 000000000000..c4c0df289472
--- /dev/null
+++ b/kernel/time/mktimeconst.c
@@ -0,0 +1,113 @@
+// SPDX-License-Identifier: 0BSD
+// Copyright 2010-2023 Rob Landley <rob@landley.net>
+
+#include <inttypes.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+
+int main(int argc, char *argv[])
+{
+	uint64_t hz, periods[] = {1000, 1000000, 1000000000};
+	char *names[] = {"MSEC", "USEC", "NSEC"};
+	FILE *file;
+	int i, j;
+
+	if (argc != 3 || (hz = atol(argv[1])) < 1
+	    || !(file = !strcmp(argv[2], "-") ? stdout : fopen(argv[2], "w"))) {
+		fprintf(stderr, "Usage: mktimeconst HZ FILENAME\n\n");
+		fprintf(stderr, "Generate a header file with constants to convert between\n");
+		fprintf(stderr, "decimal HZ timer ticks and milisecond or microsecond delays,\n");
+		fprintf(stderr, "using reciprocal multiplication to avoid 64 bit division.\n");
+		exit(1);
+	}
+
+	fprintf(file,
+		"/* Conversion constants for HZ == %"PRIu64" */\n\n"
+		"/* Automatically generated by kernel/time/mktimeconst.c */\n"
+		"/* This could be generated in __init code but isn't */\n"
+
+		"#ifndef __KERNEL_TIMECONST_H\n"
+		"#define __KERNEL_TIMECONST_H\n\n"
+		"#include <linux/param.h>\n"
+		"#include <linux/types.h>\n\n"
+		"#if HZ != %"PRIu64"\n"
+		"#error \"include/generated/timeconst.h has the wrong HZ value!\"\n"
+		"#endif\n\n", hz, hz);
+
+	/* Repeat for MSEC, USEC, and NSEC */
+
+	for (i = 0; i < 3; i++) {
+		uint64_t gcd, period;
+
+		/* Find greatest common denominator using Euclid's algorithm. */
+
+		gcd = hz;
+		period = periods[i];
+		while (period) {
+			uint64_t temp = gcd % period;
+
+			gcd = period;
+			period = temp;
+		}
+
+		/* Output both directions (HZ_TO_PERIOD and PERIOD_TO_HZ) */
+
+		for (j = 0; j < 2; j++) {
+			char name[16];
+			uint64_t from = j ? periods[i] : hz;
+			uint64_t to = j ? hz : periods[i];
+			uint64_t mul32 = 0, adj32 = 0, shift = 0;
+
+			sprintf(name, j ? "%s_TO_HZ" : "HZ_TO_%s", names[i]);
+
+			/* Figure out what shift value gives 32 significant
+			 * bits of MUL32 data.  (Worst case to=1 from=1000000
+			 * uses 52 bits, to<<shift won't overflow 64 bit math.)
+			 */
+
+			for (;;) {
+				mul32 = ((to << shift) + from - 1) / from;
+				if (mul32 >= (1UL<<31))
+					break;
+				shift++;
+			}
+
+			/* ADJ32 is just (((FROM/GCD)-1)<<SHIFT)/(FROM/GCD)
+			 * but this can overflow 64 bit math (examples, HZ=24
+			 * or HZ=122).  Worst case scenario uses 32+20+20=72
+			 * bits.  Workaround: split off bottom 32 bits and
+			 * reassemble after calculation (32+64=96 bits).
+			 */
+
+			adj32 = from / gcd;
+
+			if (shift > 32) {
+				uint64_t upper, lower;
+
+				upper = (adj32 - 1) << (shift - 32);
+				lower = (upper % adj32) << 32;
+				adj32 = ((upper/adj32) << 32) + (lower/adj32);
+			} else
+				adj32 = ((adj32 - 1) << shift) / adj32;
+
+			/* Emit the constants into the header file. */
+
+			fprintf(file, "#define %s_MUL32\tU64_C(0x%"PRIx64")\n",
+				name, mul32);
+			fprintf(file, "#define %s_ADJ32\tU64_C(0x%"PRIx64")\n",
+				name, adj32);
+			fprintf(file, "#define %s_SHR32\t%"PRIu64"\n",
+				name, shift);
+			fprintf(file, "#define %s_NUM\t\tU64_C(%"PRIu64")\n",
+				name, to/gcd);
+			fprintf(file, "#define %s_DEN\t\tU64_C(%"PRIu64")\n\n",
+				name, from/gcd);
+		}
+	}
+	fprintf(file, "#endif /* __KERNEL_TIMECONST_H */\n");
+
+	/* Notice if the disk fills up. */
+
+	fflush(file);
+}
diff --git a/kernel/time/timeconst.bc b/kernel/time/timeconst.bc
deleted file mode 100644
index 7ed0e0fb5831..000000000000
--- a/kernel/time/timeconst.bc
+++ /dev/null
@@ -1,117 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-
-scale=0
-
-define gcd(a,b) {
-	auto t;
-	while (b) {
-		t = b;
-		b = a % b;
-		a = t;
-	}
-	return a;
-}
-
-/* Division by reciprocal multiplication. */
-define fmul(b,n,d) {
-       return (2^b*n+d-1)/d;
-}
-
-/* Adjustment factor when a ceiling value is used.  Use as:
-   (imul * n) + (fmulxx * n + fadjxx) >> xx) */
-define fadj(b,n,d) {
-	auto v;
-	d = d/gcd(n,d);
-	v = 2^b*(d-1)/d;
-	return v;
-}
-
-/* Compute the appropriate mul/adj values as well as a shift count,
-   which brings the mul value into the range 2^b-1 <= x < 2^b.  Such
-   a shift value will be correct in the signed integer range and off
-   by at most one in the upper half of the unsigned range. */
-define fmuls(b,n,d) {
-	auto s, m;
-	for (s = 0; 1; s++) {
-		m = fmul(s,n,d);
-		if (m >= 2^(b-1))
-			return s;
-	}
-	return 0;
-}
-
-define timeconst(hz) {
-	print "/* Automatically generated by kernel/time/timeconst.bc */\n"
-	print "/* Time conversion constants for HZ == ", hz, " */\n"
-	print "\n"
-
-	print "#ifndef KERNEL_TIMECONST_H\n"
-	print "#define KERNEL_TIMECONST_H\n\n"
-
-	print "#include <linux/param.h>\n"
-	print "#include <linux/types.h>\n\n"
-
-	print "#if HZ != ", hz, "\n"
-	print "#error \qinclude/generated/timeconst.h has the wrong HZ value!\q\n"
-	print "#endif\n\n"
-
-	if (hz < 2) {
-		print "#error Totally bogus HZ value!\n"
-	} else {
-		s=fmuls(32,1000,hz)
-		obase=16
-		print "#define HZ_TO_MSEC_MUL32\tU64_C(0x", fmul(s,1000,hz), ")\n"
-		print "#define HZ_TO_MSEC_ADJ32\tU64_C(0x", fadj(s,1000,hz), ")\n"
-		obase=10
-		print "#define HZ_TO_MSEC_SHR32\t", s, "\n"
-
-		s=fmuls(32,hz,1000)
-		obase=16
-		print "#define MSEC_TO_HZ_MUL32\tU64_C(0x", fmul(s,hz,1000), ")\n"
-		print "#define MSEC_TO_HZ_ADJ32\tU64_C(0x", fadj(s,hz,1000), ")\n"
-		obase=10
-		print "#define MSEC_TO_HZ_SHR32\t", s, "\n"
-
-		obase=10
-		cd=gcd(hz,1000)
-		print "#define HZ_TO_MSEC_NUM\t\t", 1000/cd, "\n"
-		print "#define HZ_TO_MSEC_DEN\t\t", hz/cd, "\n"
-		print "#define MSEC_TO_HZ_NUM\t\t", hz/cd, "\n"
-		print "#define MSEC_TO_HZ_DEN\t\t", 1000/cd, "\n"
-		print "\n"
-
-		s=fmuls(32,1000000,hz)
-		obase=16
-		print "#define HZ_TO_USEC_MUL32\tU64_C(0x", fmul(s,1000000,hz), ")\n"
-		print "#define HZ_TO_USEC_ADJ32\tU64_C(0x", fadj(s,1000000,hz), ")\n"
-		obase=10
-		print "#define HZ_TO_USEC_SHR32\t", s, "\n"
-
-		s=fmuls(32,hz,1000000)
-		obase=16
-		print "#define USEC_TO_HZ_MUL32\tU64_C(0x", fmul(s,hz,1000000), ")\n"
-		print "#define USEC_TO_HZ_ADJ32\tU64_C(0x", fadj(s,hz,1000000), ")\n"
-		obase=10
-		print "#define USEC_TO_HZ_SHR32\t", s, "\n"
-
-		obase=10
-		cd=gcd(hz,1000000)
-		print "#define HZ_TO_USEC_NUM\t\t", 1000000/cd, "\n"
-		print "#define HZ_TO_USEC_DEN\t\t", hz/cd, "\n"
-		print "#define USEC_TO_HZ_NUM\t\t", hz/cd, "\n"
-		print "#define USEC_TO_HZ_DEN\t\t", 1000000/cd, "\n"
-
-		cd=gcd(hz,1000000000)
-		print "#define HZ_TO_NSEC_NUM\t\t", 1000000000/cd, "\n"
-		print "#define HZ_TO_NSEC_DEN\t\t", hz/cd, "\n"
-		print "#define NSEC_TO_HZ_NUM\t\t", hz/cd, "\n"
-		print "#define NSEC_TO_HZ_DEN\t\t", 1000000000/cd, "\n"
-		print "\n"
-
-		print "#endif /* KERNEL_TIMECONST_H */\n"
-	}
-	halt
-}
-
-hz = read();
-timeconst(hz)

Re: [PATCH 4/5] Replace timeconst.bc with mktimeconst.c

[Thomas Gleixner]

Rob!

On Tue, Feb 21 2023 at 15:00, Rob Landley wrote:

See my previous comment about Documentation. This time you even failed
to CC the maintainer of this code.

> Update of my decade-old patch replacing timeconst.pl with mktimeconst.c,
> still removing the only user of "bc" from the build.

How is 'decade-old patch' relevant changelog information?

> All that's changed since the 2015 version at:
> https://github.com/landley/aboriginal/blob/master/sources/patches/linux-noperl-timeconst.patch

That's neither interesting.

> Is one extra iteration of the loop for nanoseconds and different
> makefile plumbing calling it. In theory this could calculate the values
> at runtime in a small _init function and eliminate the header or even
> allow HZ to change at runtime.

In theory we can also build a compiler into the decompressor which
compiles and bootstraps the kernel itself, right?

> See https://lkml.iu.edu/hypermail/linux/kernel/2211.0/02589.html

I haven't seen a changelog in a while, which provides so much useless
information and lacks any content which justifies and documents the
proposed change.

>  Kbuild                    |   7 ++-
>  kernel/time/mktimeconst.c | 111 ++++++++++++++++++++++++++++++++++++
>  kernel/time/timeconst.bc  | 117 --------------------------------------

Clearly you provided evidence that the output of both tools is identical
and because you decided to reorder the defines it's not even verifyable
with diff.

But I don't even need diff to figure out that the results are not
identical:

# grep -c '#define' orig.h
25

# grep -c '#define' patched.h
31

Which means this adds 6 more unused defines to the already 8 unused
defines of today.

You clearly spent a lot of time to make this palatable to the people who
are responsible for this code.

That said, I'm not completely opposed to get rid of the bc dependency,
but if you want to sell this, then follow the documented process and
present it in a form which is acceptable.

Thanks,

        tglx

Re: [PATCH 4/5] Replace timeconst.bc with mktimeconst.c

[Rob Landley]

On 2/21/23 17:53, Thomas Gleixner wrote:
> Rob!

Yup.

> On Tue, Feb 21 2023 at 15:00, Rob Landley wrote:
> 
> See my previous comment about Documentation. This time you even failed
> to CC the maintainer of this code.

$ git show
commit c9c3395d5e3dcc6daee66c6908354d47bf98cb0c (HEAD, tag: v6.2)
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sun Feb 19 14:24:22 2023 -0800

    Linux 6.2
...
$ scripts/get_maintainer.pl 0004-*.patch
Masahiro Yamada <masahiroy@kernel.org>
(commit_signer:3/3=100%,authored:3/3=100%,added_lines:61/61=100%,removed_lines:22/22=100%)
Nicolas Schier <nicolas@fjasle.eu> (commit_signer:1/3=33%)
linux-kernel@vger.kernel.org (open list)

I cc'd who scripts/get_maintainer.pl told me to cc, when run in a 6.2 checkout.

>> Update of my decade-old patch replacing timeconst.pl with mktimeconst.c,
>> still removing the only user of "bc" from the build.
> 
> How is 'decade-old patch' relevant changelog information?

I posted these patches on
https://landley.net/toybox/downloads/binaries/mkroot/0.8.9/linux-patches/ and
https://github.com/landley/linux/commits/mkroot-6.1 when I did the toybox
release where the mkroot binary system images were built from this stuff. The
descriptions mostly come from there. None of the people I interact with
regularly bothers to talk to linux-kernel anymore, they think you're too toxic
to ever contact. I'm weird for tolerating you.

Posting it here involved retesting all the targets against 6.2 and digging up a
thunderbird plugin to get it to stop wrapping lines (old one bit-rotted and is
no longer maintained) and silencing various check_patch.pl complaints about
curly bracket placement and so on. But not a lot of rewriting the descriptions.
It wouldn't help.

This particular patch is coming up on 15 years of ancestry
(https://lore.kernel.org/all/200912080319.30679.rob@landley.net/) so I really
don't expect linux-kernel to merge... anything anymore?

I'd have thought the "$ARCH-cross-cc toolchains just work whether they're gcc or
llvm without needing to tell make LLVM=1 but not GCC=1" patch was a no-brainer,
or the one that fixes an obvious bug in my own code from 10 years ago which
multiple people have poked me about and I finally bothered to do something
about, or the one where "hey, you have a CONFIG_DEVTMPFS_MOUNT and it doesn't
work for initramfs, that seems like a bug".

But that just shows I'm out of step with this community. I remember when posting
a simple patch would give someone the idea and they'd write their own as often
as merge mine because it was just easy to do. Hasn't been the case here in quite
a while.

>> All that's changed since the 2015 version at:
>> https://github.com/landley/aboriginal/blob/master/sources/patches/linux-noperl-timeconst.patch
> 
> That's neither interesting.

"This area of the existing linux code is not regularly updated, replacing it
does not imply a large future maintenance burden."

>> Is one extra iteration of the loop for nanoseconds and different
>> makefile plumbing calling it. In theory this could calculate the values
>> at runtime in a small _init function and eliminate the header or even
>> allow HZ to change at runtime.
> 
> In theory we can also build a compiler into the decompressor which
> compiles and bootstraps the kernel itself, right?

Fabrice Bellard did that in 2004:

https://bellard.org/tcc/tccboot.html

I maintained a fork of tinycc for ~3 years in hopes of extending it to build an
unmodified vanilla kernel, but was stretched too thin between too many projects:

https://landley.net/hg/tinycc

My proposed sequel project was gluing qemu's tcg (tiny code generator) to tcc's
front-end to get a maybe 150k line C compiler that could target every hardware
platform qemu supports:

https://landley.net/qcc/

But again, stretched too thin between too many other projects, didn't have the
spoons.

By the way, part of my motivation for all that was "countering trusting trust":

http://lists.landley.net/pipermail/toybox-landley.net/2020-July/011898.html

And part is minix and xv6 are restricted systems which explicitly reject
anything that would make them load bearing for real world usage (the patch
backlog on comp.os.minix from people who TRIED and couldn't get their patches
merged is how Linux went from 0.0.1 to 0.9.5 so fast).

It would be nice if people could study the base for real world usage in an
isolated reproducible context with minimal circular dependencies. (If you can't
reproduce it from first principles in a laboratory environment, what you're
doing isn't science.)

There was a time where Linux straddled that divide, but these days it seems more
likely that https://www.youtube.com/watch?v=Ce1pMlZO_mI or similar will "grow
legs" and become load bearing than that linux-kernel will get taught in high
schools.

>> See https://lkml.iu.edu/hypermail/linux/kernel/2211.0/02589.html
> 
> I haven't seen a changelog in a while, which provides so much useless
> information and lacks any content which justifies and documents the
> proposed change.

You should get out more.

You guys didn't consider "reduce gratuitous build dependencies" to be inherently
useful back when it was perl removal either. That's why I maintain my own
patches. I expect I'll probably switch to a simpler kernel when you finally make
it so nobody can build the linux without C _and_ rust compilers, which doesn't
seem far off. But we'll see...

>>  Kbuild                    |   7 ++-
>>  kernel/time/mktimeconst.c | 111 ++++++++++++++++++++++++++++++++++++
>>  kernel/time/timeconst.bc  | 117 --------------------------------------
> 
> Clearly you provided evidence that the output of both tools is identical

I checked that way back when, but producing exactly identical output didn't get
it merged.

This time I think I just read through the changelog on the bc tool and made the
minimal changes necessary to produce identical kernel binaries on all the
https://landley.net/toybox/downloads/binaries/mkroot/0.8.9/ targets but it was a
while ago now...

> and because you decided to reorder the defines it's not even verifyable
> with diff.
> 
> But I don't even need diff to figure out that the results are not
> identical:
> 
> # grep -c '#define' orig.h
> 25
> 
> # grep -c '#define' patched.h
> 31
> 
> Which means this adds 6 more unused defines to the already 8 unused
> defines of today.

It produces consistent output for each of the units. I wasn't trying to
determine why the existing code was producing unused defines, or why it
reordered the defines since I wrote the first version. That's social context I
don't have, I'm not a full-time member of the kernel clique.

> You clearly spent a lot of time to make this palatable to the people who
> are responsible for this code.

After 14 years? Not so much. Various people pick things up from linux-kernel...
and then email me privately. Sigh.

> That said, I'm not completely opposed to get rid of the bc dependency,
> but if you want to sell this, then follow the documented process and
> present it in a form which is acceptable.

I've been maintaining this particular patch on and off long enough it'll be
eligible to vote soon. Posting it to linux-kernel means other people with their
own dirty trees can pick it up, and where lawyers and/or a judge who want to
give me grief can be easily shown "I delivered it to the kernel community in the
community's official channel, not just once but multiple times, collated and run
through their get_maintainer.pl and check_patch.pl, and _they_ chose not to
merge it for their own reasons"...

Getting it merged, so I could stop, would be nice. So would winning the lottery.
I'm happy to make changes if you think they'll accomplish anything? But I've
done that before. Here's v4 of the DEVTMPFS_MOUNT patch, for example:

https://lkml.iu.edu/hypermail/linux/kernel/2005.1/09399.html

Rinse repeat, same old same old...

> Thanks,
> 
>         tglx

Rob

[PATCH 5/5] fix rootfstype=tmpfs

[Rob Landley]

Wire up rootfstype=tmpfs to force rootfs to be tmpfs even when you specify root=

Initramfs automatically uses tmpfs (if available) when you DON'T specify a
root= fallback root to mount over initramfs, but some people can't NOT do
that for some reason (old bootloaders), so let rootfstype=tmpfs override it.

My original code tried to do this 10 years ago but got the test wrong,
and nobody's corrected it since, so here you go...

Signed-off-by: Rob Landley <rob@landley.net>

See https://lkml.iu.edu/hypermail/linux/kernel/2207.3/06939.html
---
 init/do_mounts.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/init/do_mounts.c b/init/do_mounts.c
index 811e94daf0a8..01d80fb828fd 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -665,7 +665,7 @@ struct file_system_type rootfs_fs_type = {
 
 void __init init_rootfs(void)
 {
-	if (IS_ENABLED(CONFIG_TMPFS) && !saved_root_name[0] &&
-		(!root_fs_names || strstr(root_fs_names, "tmpfs")))
+	if (IS_ENABLED(CONFIG_TMPFS) && (!root_fs_names ? !saved_root_name[0] :
+		!!strstr(root_fs_names, "tmpfs")))
 		is_tmpfs = true;
 }

Re: [PATCH 5/5] fix rootfstype=tmpfs

[Stefan Berger]

On 2/21/23 16:04, Rob Landley wrote:
> Wire up rootfstype=tmpfs to force rootfs to be tmpfs even when you specify root=
> 
> Initramfs automatically uses tmpfs (if available) when you DON'T specify a
> root= fallback root to mount over initramfs, but some people can't NOT do
> that for some reason (old bootloaders), so let rootfstype=tmpfs override it.
> 
> My original code tried to do this 10 years ago but got the test wrong,
> and nobody's corrected it since, so here you go...
> 
> Signed-off-by: Rob Landley <rob@landley.net>

I would like to be able to have this for some work with OpenBMC and 
ideally it would propagate to one of the recent kernels with a Fixes tag 
like this?

Fixes: 6e19eded3684 ("initmpfs: use initramfs if rootfstype= or root= 
specified")

Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>

> 
> See https://lkml.iu.edu/hypermail/linux/kernel/2207.3/06939.html
> ---
>   init/do_mounts.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/init/do_mounts.c b/init/do_mounts.c
> index 811e94daf0a8..01d80fb828fd 100644
> --- a/init/do_mounts.c
> +++ b/init/do_mounts.c
> @@ -665,7 +665,7 @@ struct file_system_type rootfs_fs_type = {
>   
>   void __init init_rootfs(void)
>   {
> -	if (IS_ENABLED(CONFIG_TMPFS) && !saved_root_name[0] &&
> -		(!root_fs_names || strstr(root_fs_names, "tmpfs")))
> +	if (IS_ENABLED(CONFIG_TMPFS) && (!root_fs_names ? !saved_root_name[0] :
> +		!!strstr(root_fs_names, "tmpfs")))
>   		is_tmpfs = true;
>   }

Re: [PATCH 5/5] fix rootfstype=tmpfs

[Stefan Berger]

On 11/1/23 09:10, Stefan Berger wrote:
> 
> 
> On 2/21/23 16:04, Rob Landley wrote:
>> Wire up rootfstype=tmpfs to force rootfs to be tmpfs even when you 
>> specify root=
>>
>> Initramfs automatically uses tmpfs (if available) when you DON'T 
>> specify a
>> root= fallback root to mount over initramfs, but some people can't NOT do

can't NOT -> cannot

>> that for some reason (old bootloaders), so let rootfstype=tmpfs 
>> override it.
>>
>> My original code tried to do this 10 years ago but got the test wrong,
>> and nobody's corrected it since, so here you go...

I think this sentence can be dropped.

>>
>> Signed-off-by: Rob Landley <rob@landley.net>
> 
> I would like to be able to have this for some work with OpenBMC and 
> ideally it would propagate to one of the recent kernels with a Fixes tag 
> like this?
> 

Can you repost this patch or should I do it?

Regards,
    Stefan

> Fixes: 6e19eded3684 ("initmpfs: use initramfs if rootfstype= or root= 
> specified")
> 
> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
> Tested-by: Stefan Berger <stefanb@linux.ibm.com>


> 
>>
>> See https://lkml.iu.edu/hypermail/linux/kernel/2207.3/06939.html
>> ---
>>   init/do_mounts.c | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/init/do_mounts.c b/init/do_mounts.c
>> index 811e94daf0a8..01d80fb828fd 100644
>> --- a/init/do_mounts.c
>> +++ b/init/do_mounts.c
>> @@ -665,7 +665,7 @@ struct file_system_type rootfs_fs_type = {
>>   void __init init_rootfs(void)
>>   {
>> -    if (IS_ENABLED(CONFIG_TMPFS) && !saved_root_name[0] &&
>> -        (!root_fs_names || strstr(root_fs_names, "tmpfs")))
>> +    if (IS_ENABLED(CONFIG_TMPFS) && (!root_fs_names ? 
>> !saved_root_name[0] :
>> +        !!strstr(root_fs_names, "tmpfs")))
>>           is_tmpfs = true;
>>   }

Re: [PATCH 5/5] fix rootfstype=tmpfs

[Rob Landley]

[-- Attachment #1: Type: text/plain, Size: 1224 bytes --]

On 11/8/23 16:05, Stefan Berger wrote:
> On 11/1/23 09:10, Stefan Berger wrote:
>> On 2/21/23 16:04, Rob Landley wrote:
>>> Wire up rootfstype=tmpfs to force rootfs to be tmpfs even when you 
>>> specify root=
>>>
>>> Initramfs automatically uses tmpfs (if available) when you DON'T 
>>> specify a
>>> root= fallback root to mount over initramfs, but some people can't NOT do
> 
> can't NOT -> cannot

The double negative was intentional for emphasis, hence the capitalization. They
are unable to refrain from doing. "Could you just... not do that?" "No, I cannot
not do that."

But if you want to phrase it differently, go ahead.

>>> that for some reason (old bootloaders), so let rootfstype=tmpfs 
>>> override it.
>>>
>>> My original code tried to do this 10 years ago but got the test wrong,
>>> and nobody's corrected it since, so here you go...
> 
> I think this sentence can be dropped.

If you like.

>>>
>>> Signed-off-by: Rob Landley <rob@landley.net>
>> 
>> I would like to be able to have this for some work with OpenBMC and 
>> ideally it would propagate to one of the recent kernels with a Fixes tag 
>> like this? 
> 
> Can you repost this patch or should I do it?

They're more likely to listen to you.

Rob

[-- Attachment #2: patches.tgz --]
[-- Type: application/x-compressed-tar, Size: 8137 bytes --]

Re: [PATCH 5/5] fix rootfstype=tmpfs

[Rob Landley]

On 11/9/23 10:42, Rob Landley wrote:
> On 11/8/23 16:05, Stefan Berger wrote:
>> Can you repost this patch or should I do it?
> 
> They're more likely to listen to you.

P.S. I have a pile of local kernel patches (accidentally attached to the
_previous_ message, but decided this part was not good to post to lkml) that
I've despaired of upstream ever being interested in, and have "rebase/test them
all on 6.6 kernel for the ~dozen architectures I track"
(https://landley.net/bin/mkroot/latest/) as a local todo item I haven't gotten
to yet. It's on the "list of things I feel guilty about not having done yet".
Speaking of which:

Hi Andrew! I'm sorry I didn't reply to your last email on the list (and instead
just blogged about it, https://landley.net/notes-2023.html#24-02-2023 and
blogged about feeling guilty about still having not replied on April 11 and June
25), but is I cc'd the people scripts/get_maintainer.pl said to, and if that's
no longer enough I don't even _pretend_ to understand the process here anymore,
but don't know how to say that without being political.

Take this reposting thing: clearly you HAVE the patch. That's not the issue. And
it's not a The-SCO-Lawsuit-scared-us-by: permission-to-use issue either, because
I posted it to the list with all the paperwork filled out as best I know how,
which I _think_ was recently acknowledged by the person multiple steps up the
chain of the approval process.

I'm _guessing_ the issue here is the need to refile the paperwork to officially
restart a multi-step bureaucratic process, with nothing actually having changed
since last time that I can tell. Possibly just put the expired form back in the
inbox and let literally the same one go through again like a janky dollar bill
scanner.

I'm very bad at sticking the form in the slot and hoping someone will eventually
see it, with the form getting lost vs being denied looking exactly the same for
an indeterminate period of time. I travel to places in person and wait in long
lines and show ID to get to talk to a human where possible. Linux-kernel hasn't
really provided that option for quite a while.

And I didn't want to say _that_ either. It seems impolite. You are full-time
kernel developers, and I am not. I'm not here to criticize your process, I've
just been unable to meaningfully participate in the impersonal bureaucracy it's
become since... I think I gave up in 2017? https://lkml.org/lkml/2017/9/17/1 is
still in my patch list. I'd happily drop it if upstream had fixed it a different
way, but it's been 8 years. That "all bugs are shallow" open source code review
stuff demonstrably stopped working for this project quite some time ago.

Rob

Re: [PATCH 5/5] fix rootfstype=tmpfs

[Rob Landley]

On 11/9/23 10:46, Rob Landley wrote:
> On 11/9/23 10:42, Rob Landley wrote:
>> On 11/8/23 16:05, Stefan Berger wrote:
>>> Can you repost this patch or should I do it?
>> 
>> They're more likely to listen to you.
> 
> P.S. I have a pile of local kernel patches (accidentally attached to the
> _previous_ message, but decided this part was not good to post to lkml)

Thank you, Thunderbird, for not actually updating the "to" list with changes
you've made until you click away to give focus to a different GUI field, and
clicking "send" does not count.

Rob

Re: [PATCH 0/5] Patches used to build mkroot.

[Andrew Morton]

On Tue, 21 Feb 2023 14:53:30 -0600 Rob Landley <rob@landley.net> wrote:

> The ~300 line bash script in toybox that builds bootable Linux systems
> for a dozen-ish targets can use a vanilla kernel, but the binaries I
> ship are built from a kernel with these patches:

It's nice to see a diffstat of the whole series to at least get an idea
of who might merge the series.

Who were you thinking might merge the series?  I was only cc'ed on two
of them, I think.

There is no "Previously:" changelog tag.  Please use plain old "Link:".

Also, "See https://..." after the "^---$" will get chopped off.  It
might be helpful to includes this also as a Link: tag.