On Thu, Feb 20, 2025 at 09:31:14AM -0700, Jeffrey Hugo wrote:
On 2/20/2025 8:54 AM, Nicolas Schier wrote:
On Thu, Feb 20, 2025 at 08:03:32AM -0700, Jeffrey Hugo wrote:
On 2/20/2025 3:03 AM, Nicolas Schier wrote:
On Tue, Feb 18, 2025 at 01:25:38PM -0700, Jeffrey Hugo wrote:
On 7/27/2024 1:42 AM, Masahiro Yamada wrote:
Exclude directories and files unnecessary for building external modules:
- include/config/ (except include/config/auto.conf)
- scripts/atomic/
- scripts/dtc/
- scripts/kconfig/
- scripts/mod/mk_elfconfig
- scripts/package/
- scripts/unifdef
- .config
Please revert this (the removal of .config).
I got some strange reports that our external module install broke, and
traced it to this change. Our external module references the .config
because we have different logic for the build depending on if other, related
modules are present or not.
Also, it looks like this broke DKMS for some configurations, which not only
impacts DKMS itself [1] but also downstream projects [2].
While DKMS may be updated going forward to avoid this issue, there are
plenty of affected version out in the wild.
Also, I haven't surveyed every distro, but it looks like Ubuntu still
packages the .config with their headers in their upcoming "Plucky" release
based on 6.12. I suspect they wouldn't do that if they didn't feel it was
needed/useful.
-Jeff
[1]: https://github.com/dell/dkms/issues/464
[2]: https://github.com/linux-surface/linux-surface/issues/1654
Hi Jeff,
do you know the related thread [1]? According to the last mail, DKMS
has fixed its issue already in December.
DKMS tip might be fixed, but production versions are in various distros,
which are not updated. Therefore actual users are impacted by this.
What happened to the #1 rule of kernel, that we do not break users?
I think, Masahiro already provided valid and profound reasons for
keeping it the way it is. Users of run-time kernel interfaces are not
affected by the change. Concretely reported issues were, as far as I
know, only a matter of specific non-official way to work with .config
for other reasons than just building external kernel modules in the way
it is thought to work.
I'm CCing the regressions list, which I probably should have done initially.
I'm pretty sure Linus has indicated that as soon as users start doing
something, that becomes the "official way". I believe your response is not
consistent with the precedent set by Linus.
Quoting from [1]:
It’s a regression if some application or practical use case running fine
with one Linux kernel works worse or not at all with a newer version
compiled using a similar configuration. The “no regressions” rule forbids
this to take place; if it happens by accident, developers that caused it are
expected to quickly fix the issue."
Regressions are at runtime, not with how external tools poke around in
kernel source trees and try to make decisions. If we were to never be
able to change our source just because there might be an external user
that we don't know of, that would be crazy.
We want users to not be afraid to upgrade their kernel, that has nothing> >> As far as I understand its not acceptable to force users to change (the DKMS
to do with how the kernel build is interacted with external stuff.
fix) or update userspace to work with a new kernel. You could make a change
if userspace updated, and all old versions needing the previous behavior
were phased out of use, but we have 2 reports indicating that is not the
case.
You are attempting to build kernel modules outside of the kernel tree,
and as such, have to adapt to things when they change. That's always
been the case, you've had to change things many times over the years,
right?
From the thread you pointed out, it looks like Masahiro recommends
${kernel_source_dir}/include/config/auto.conf as a replacement for the
.config. Ignoring that such a suggestion seems to violate the regressions
rule, doing a diff of that and the .config on a 6.11 build (before the
change we are discussing), there are many changes. It does not look like
that is an equivalent replacement.
What do you need/want to parse the .config file in the first place? Why
not rely on the generated .h files instead as those can be parsed the
same way as before, right?