Message-ID: <092a70e9-12c1-29fd-1fb0-fd851024de39@meinberg.de>
Date:   Tue, 18 Aug 2020 22:50:43 +0200
From:   Martin Burnicki <martin.burnicki@...nberg.de>
To:     Masahiro Yamada <masahiroy@...nel.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Randy Dunlap <rdunlap@...radead.org>
Subject: Re: Kernel build system broken in 5.8?

Hello Masahiro,

Masahiro Yamada wrote:
> On Wed, Aug 19, 2020 at 1:14 AM Martin Burnicki
> <martin.burnicki@...nberg.de> wrote:
[...]
>> I usually build the kernel module as standard user, and only install the
>> new module as root, e.g.:
>>
>>   git checkout devel   # The 'devel' branch is appropriate for testing
>>   cd mbgclock          # the subdirectory of the kernel module
>>   git clean -fd; make  # or make V=1 for verbose output
>>   sudo make install
> 
> 
> This is a bad way for reporting a bug
> because your project is too big.

Sorry for this. I wasn't sure which was the best way to get a contact to
folks who are more familiar with details of the kernel build system, and
what may have been changed.

A possibility could have

> mbgclock/Makefile include the top Makefile,
> which is more than 1000 lines.

If you run 'make' in the mbgclock subdirectory then the kernel build
system is just called as usual, i.e.

  make -C <path-to-the-kernel-build-system> M=$PWD <some EXTRA_CFLAGS>

This has been working without problems for many years, for many popular
distros, and all kernels from 2.6 up to 5.7 (except that for older
kernels SUBDIRS=$PWD was used instead of M=$PWD).

> Please provide steps to reproduce it
> with a tiny test module.

I was just hoping that someone had an idea like "Oh, this is because xyz
has changed in kernel 5.18" when he read what I've observed.

In the past I've seen cases where folks e.g. from RedHat or SuSE had
backported patches from newer kernels to older ones, causing build
errors in my driver code, and I was able to apply workarounds to my
source code.

However, this case is different because obviously the kernel source tree
is modified under certain circumstances. Is my assumption correct that
this should not happen if I install Linux header packages for a distro,
that have been pre-configured according to the running kernel?

Anyway, I'm going to try to set up an example which makes it easier to
duplicate the problem.

> You state 5.7.15 was fine.

Yes.

> So, could you also run git-bisect, please?

Sorry, I've just recently started using git, and yet I'm not too
familiar with some of the commands. How could git-bisect help in this case?

>> Also, I was under the impression that the kernel source tree should be
>> read-only, and kept clean, but this doesn't seem to be the case anymore.
>>
>>
>> For example:
>>
>> On Ubuntu 19.10 with kernel 5.8.1-050801-generic from
>> https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.8.1/
> 
> 
> I cannot try it since that is not what
> I install on my machine, sorry.

What distro are you using? Or do you only run kernels you have compiled
yourself? ;-)

> Please provide steps to reproduce it
> for a person using a different environment.

I'm going to try to do this. Do you have any hints what this should look
like?

Should this topic be continued on linux-kernel@, or better on
linux-kbuild@, or elsewhere?


Thanks,

Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burnicki@...nberg.de
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de  https://www.meinbergglobal.com
Training: https://www.meinberg.academy

Powered by blists - more mailing lists