Message-ID: <668a287b-7c21-7f97-5703-67dcfe021006@landley.net>
Date:   Wed, 22 Feb 2023 16:52:12 -0600
From:   Rob Landley <rob@...dley.net>
To:     Thomas Gleixner <tglx@...utronix.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Cc:     Masahiro Yamada <masahiroy@...nel.org>,
        Nicolas Schier <nicolas@...sle.eu>
Subject: Re: [PATCH 4/5] Replace timeconst.bc with mktimeconst.c

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@...ux-foundation.org>
Date:   Sun Feb 19 14:24:22 2023 -0800

    Linux 6.2
...
$ scripts/get_maintainer.pl 0004-*.patch
Masahiro Yamada <masahiroy@...nel.org>
(commit_signer:3/3=100%,authored:3/3=100%,added_lines:61/61=100%,removed_lines:22/22=100%)
Nicolas Schier <nicolas@...sle.eu> (commit_signer:1/3=33%)
linux-kernel@...r.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

Powered by blists - more mailing lists