Message-ID: <20230711193608.GD31402@1wt.eu>
Date:   Tue, 11 Jul 2023 21:36:08 +0200
From:   Willy Tarreau <w@....eu>
To:     Zhangjin Wu <falcon@...ylab.org>
Cc:     arnd@...db.de, linux-kernel@...r.kernel.org,
        linux-kselftest@...r.kernel.org, thomas@...ch.de
Subject: Re: [PATCH v1 00/22] selftests/nolibc: add minimal kernel config
 support

On Wed, Jul 12, 2023 at 01:18:26AM +0800, Zhangjin Wu wrote:
> > > With the new patchset, it is able to rebuild and rerun everything in several
> > > minutes, it may make people very happy to develop nolibc itself and also make
> > > people to work on linux with nolibc, especially for developing and testing a
> > > new kernel feature ;-)
> > 
> > I doubt it. Rebuilding everything is not what most developers need. What
> > they need is to just fix a missing parenthesis that broke the build and
> > rebuild the strict minimum, restarting from where they left. And they
> > need to be able to figure what caused that "FAILED" output, disassemble
> > the output, re-run it manually under qemu-user, rebuild the .c manually
> > after copy-pasting the whole command line via "V=1", etc.
> >
> 
> It is mainly for a cross arch change, like the _start_c() patchset we
> just discuss. This may also happen for every release (not that helpful,
> for a new release, a mrproper or distclean may be required).

Maybe, but let's focus on fixing what's really annoying before trying
to improve things that work. If you find yourself failing to do certain
things, annoyed with some flags that are forced on you etc, not finding
a way to work with multiple output dirs, these are good reasons for
applying changes. But thinking that it will likely be better organized
this or that way tends to make us forget what we're relying on and that
we might lose by accident.

> > Keep in mind that the purpose of a selftest is not to optimize the case
> > where it works fine, but to optimize the developer's work when it fails.
> > This is something that a lot of people tend to get wrong. They're proud
> > of a "make world" that does everything including delivering them pizzas
> > to wait for the builds to complete, and they say "hey, impressed?". But
> > when someone else reports "I'm getting this strange error I don't
> > understand", they can hardly suggest more than "hmmm run make clean, try
> > again, or use the same distro as me because it works for me".
> >
> 
> Parts of them do want to meet the 'optimize the developer's work when it
> fails', for example, new developers may be hard to find a loongarch or
> riscv bios, or find a toolchain for the not frequently used
> architecture, to avoid introduce many bug reports about "strange errors"
> outside of our core functions, perhaps we'd better do these in a nolibc
> doc under Documentation/, tell people how to prepare the develop and
> test environment of nolibc and how to use nolibc there.

Reading the beginning of the sentence made me immediately think that it's
what doc is for. You know, if you give a fish to a hungry man he eats one
day, if you teach him to fish he eats every day. Knowing what to download
from where is much more instructive than running "make download" or even
worse, "make" and having the downloads secretly succeed (or fail). If you
think the doc is hard to find I'm also fine with a patch for makefile
and/or nolibc-test passing a pointer to its location as a reminding
comment for example.

> > And I think that helping the user
> > prepare certain steps or iterate over architectures *is* useful. When
> > you do it in two layers (the script replacing the user, the makefile
> > doing the build job), it remains easy and convenient to use, and you
> > can pick only what you need (e.g. "please build musl for me"). And if
> > something goes wrong, it's simple for the user to takeover and complete
> > that failed task by changing an arch name, a directory or anything, and
> > have their tools ready. Let's just never make that automatic for the
> > sake of everyone's health!
> 
> Ok, the revision will align with the original Makefile and remove the automatic
> parts and no change about the OUTPUT.

Just check that you can force it from your script on the make command
line. If you see that it's not possible, we should do something because
I don't want to force you to make distclean all the time if not needed.
But if you find that passing certain options (O=, OUTPUT= or anything
else) does the job, it only needs to be documented.

Thanks,
Willy

Powered by blists - more mailing lists