* Possible Regression Regarding bcf637f5 interfering with dkms automatic module builds
@ 2021-03-27 21:02 John S Gruber
0 siblings, 0 replies; 2+ messages in thread
From: John S Gruber @ 2021-03-27 21:02 UTC (permalink / raw
To: linux-kbuild
I've run into a problem installing 5.12 test kernels. When dkms tries
to build a module invoked by kernel make install it cleans the linux
tree and tries to do a make modules there (both by root). The dkms
module is left unbuilt.
I bisected to the above commit -- kbuild: parse C= and M= before
changing the working directory
This commit changes the main Makefile so that make doesn't parse the
M= parameter if the variable sub_make_done is in the environment and
set to 1.
On my and on similar systems make install uses /sbin/installkernel to
do the installation. /sbin/installkernel uses run-parts on
/etc/kernel/postinst.d/ to perform various elements in the
installation, e.g. boot loader configuration. One of these is dkms to
build an out-of-tree module. dkms autoinstall then attempts to make
clear and make build the module(s) in a source directory using the
linux source tree.
The sub_make_done=1 variable is still in the environment after all
this and the above make commands therefore don't parse the necessary
M= parameter pointing to the source tree. Thus the initiated make
invocations, ignoring the two parameters, process against the linux
source tree instead.
I was able to get proper function by unsetting sub_make_done in either
dkms or in arch/x86/boot/install.sh
This kind of problem is obtuse enough I wonder if the optimization
attempted in the above commit is worth the complexity. On the other
hand if it produces meaningful performance improvement perhaps changes
to the architecture Makefiles or install scripts could be patched.
I'd be happy to test patches on my system. Are there any questions or
issues I've neglected?
Thanks.
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Possible Regression Regarding bcf637f5 interfering with dkms automatic module builds
[not found] <CAPotdmSVe-0iRfoCpSuTa-kR3V-QQKw2QG6PbQkP21gaBhd2Xw@mail.gmail.com>
@ 2021-03-29 14:22 ` Masahiro Yamada
0 siblings, 0 replies; 2+ messages in thread
From: Masahiro Yamada @ 2021-03-29 14:22 UTC (permalink / raw
To: John S Gruber; +Cc: Linux Kbuild mailing list
On Sun, Mar 28, 2021 at 5:53 AM John S Gruber <johnsgruber@gmail.com> wrote:
>
> I've run into a problem installing 5.12 test kernels. When dkms tries to build a module invoked by kernel make install it cleans the linux tree and tries to do a make modules there (both by root). The dkms module is left unbuilt.
>
> I bisected to the above commit -- kbuild: parse C= and M= before changing the working directory
>
> This commit changes the main Makefile so that make doesn't parse the M= parameter if the variable sub_make_done is in the environment and set to 1.
>
> On my and on similar systems make install uses /sbin/installkernel to do the installation. /sbin/installkernel uses run-parts on /etc/kernel/postinst.d/ to perform various elements in the installation, e.g. boot loader configuration. One of these is dkms to build an out-of-tree module. dkms autoinstall then attempts to make clear and make build the module(s) in a source directory using the linux source tree.
>
> The sub_make_done=1 variable is still in the environment after all this and the above make commands therefore don't parse the necessary M= parameter pointing to the source tree. Thus the initiated make invocations, ignoring the two parameters, process against the linux source tree instead.
>
> I was able to get proper function by unsetting sub_make_done in either dkms or in arch/x86/boot/install.sh
>
> This kind of problem is obtuse enough I wonder if the optimization attempted in the above commit is worth the complexity. On the other hand if it produces meaningful performance improvement perhaps changes to the architecture Makefiles or install scripts could be patched.
If my motivation were such small performance improvement,
I would agree to revert bcf637f54f6d2515d4c9c81808faf01848916152.
Actually, bcf637f54f6d2515d4c9c81808faf01848916152 is a prerequisite
of my future improvement for external module builds,
(but I have not been able to find enough time to complete my work,
and presumably I cannot send patches any time soon).
So, it is unfortunate dkms is hooked by arch/x86/boot/install.sh
One down-side is that external modules are built under the root privilege.
In general, building should be done by a normal user, and installation
should be done by the root user.
But, I do not have a better idea than doing that in
the arch/x86/boot/install.sh hook.
> I'd be happy to test patches on my system. Are there any questions or issues I've neglected?
>
> Thanks.
--
Best Regards
Masahiro Yamada
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2021-03-29 14:24 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <CAPotdmSVe-0iRfoCpSuTa-kR3V-QQKw2QG6PbQkP21gaBhd2Xw@mail.gmail.com>
2021-03-29 14:22 ` Possible Regression Regarding bcf637f5 interfering with dkms automatic module builds Masahiro Yamada
2021-03-27 21:02 John S Gruber
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.