[PATCH] modprobe: install default configuration

[PATCH] modprobe: install default configuration

[Lubomir Rintel]

Some network devices have an awful habit of creating interfaces when loaded,
despite not asked for. Worse even, they do so while being autoloaded due to an
attempt to create a device via netlink:

  # rmmod dummy
  # ip link add dummy0 type dummy
  RTNETLINK answers: File exists

The kernel maintainers seem opposed to fixing this in kernel (despite a similar
thing has been done with loop block devices) [1]. Let's fix this my overriding the
defaults from userspace.

[1] http://comments.gmane.org/gmane.linux.kernel/2124714
---
 Makefile.am                |  4 ++++
 modprobe.d/50-default.conf | 24 ++++++++++++++++++++++++
 2 files changed, 28 insertions(+)
 create mode 100644 modprobe.d/50-default.conf

diff --git a/Makefile.am b/Makefile.am
index 2d9f2cf..9f89485 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -103,6 +103,10 @@ bashcompletiondir=@bashcompletiondir@
 dist_bashcompletion_DATA = \
 	shell-completion/bash/kmod
 
+modprobeddir=$(prefix)/lib/modprobe.d
+dist_modprobed_DATA = \
+	modprobe.d/50-default.conf
+
 install-exec-hook:
 	if test "$(libdir)" != "$(rootlibdir)"; then \
 		$(MKDIR_P) $(DESTDIR)$(rootlibdir) && \
diff --git a/modprobe.d/50-default.conf b/modprobe.d/50-default.conf
new file mode 100644
index 0000000..70d21f2
--- /dev/null
+++ b/modprobe.d/50-default.conf
@@ -0,0 +1,24 @@
+# default module parameters
+#
+# This file is part of kmod.
+#
+# Copyright 2016 Lubomir Rintel
+#
+# This program is free software; you can redistribute it and/or modify it
+# under the terms of the GNU Lesser General Public License as published by
+# the Free Software Foundation; either version 2.1 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+# General Public License for more details.
+#
+# You should have received a copy of the GNU Lesser General Public License
+# along with this program; if not, see <http://www.gnu.org/licenses/>.
+
+# See modprobe.d(5) for the description of the files in this directory,
+
+options bonding max_bonds=0
+options dummy numdummies=0
+options ifb numifbs=0
-- 
2.5.0

Re: [PATCH] modprobe: install default configuration

[Marco d'Itri]

[-- Attachment #1: Type: text/plain, Size: 385 bytes --]

On Mar 02, Lubomir Rintel <lkundrak@v3.sk> wrote:

> The kernel maintainers seem opposed to fixing this in kernel (despite a similar
> thing has been done with loop block devices) [1]. Let's fix this my overriding the
> defaults from userspace.
Because, guess what? This breaks userspace.
Feel free to configure your system this way if it is what you want.

-- 
ciao,
Marco

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 648 bytes --]

Re: [PATCH] modprobe: install default configuration

[De Marchi, Lucas]

T24gV2VkLCAyMDE2LTAzLTAyIGF0IDE2OjU1ICswMTAwLCBNYXJjbyBkJ0l0cmkgd3JvdGU6DQo+
IE9uIE1hciAwMiwgTHVib21pciBSaW50ZWwgPGxrdW5kcmFrQHYzLnNrPiB3cm90ZToNCj4gDQo+
ID4gDQo+ID4gVGhlIGtlcm5lbCBtYWludGFpbmVycyBzZWVtIG9wcG9zZWQgdG8gZml4aW5nIHRo
aXMgaW4ga2VybmVsDQo+ID4gKGRlc3BpdGUgYSBzaW1pbGFyDQo+ID4gdGhpbmcgaGFzIGJlZW4g
ZG9uZSB3aXRoIGxvb3AgYmxvY2sgZGV2aWNlcykgWzFdLiBMZXQncyBmaXggdGhpcyBteQ0KPiA+
IG92ZXJyaWRpbmcgdGhlDQo+ID4gZGVmYXVsdHMgZnJvbSB1c2Vyc3BhY2UuDQo+IEJlY2F1c2Us
IGd1ZXNzIHdoYXQ/IFRoaXMgYnJlYWtzIHVzZXJzcGFjZS4NCj4gRmVlbCBmcmVlIHRvIGNvbmZp
Z3VyZSB5b3VyIHN5c3RlbSB0aGlzIHdheSBpZiBpdCBpcyB3aGF0IHlvdSB3YW50Lg0KDQpNb3Jl
IGNvbnRleHQ6wqBodHRwczovL2dpdGh1Yi5jb20vc3lzdGVtZC9zeXN0ZW1kL3B1bGwvMjc3OA0K
DQpNYXJjbywgY291bGQgeW91IGJlIG1vcmUgc3BlY2lmaWMgb24gaG93IHRoaXMgYnJlYWtzIHVz
ZXJzcGFjZT8gSXQNCnNlZW1zIGFscmVhZHkgcHJldHR5IG11Y2ggYnJva2VuIHRvIG1lLiBXZSBj
YW4gZXZlbiBhcmd1ZSBpZiBwZW9wbGUNCndhbnRzIHRoZSBicm9rZW4gc3lzdGVtIGJhY2sgdGhl
eSBjYW4gZXF1YWxseSB3ZWxsIGNvbmZpZ3VyZSB0aGVpcg0Kc3lzdGVtIHRvIGRvIHRoYXQgKGV2
ZW4gcHV0dGluZyBvbiAvZXRjIHRvIG92ZXJyaWRlIHdoYXQgd2FzIHNldCBvbg0KL3Vzci9saWIp
Lg0KDQpUaGUgY29tbWl0IG1lc3NhZ2UgZG9lc24ndCByZWZsZWN0IHRoZSBmZWVkYmFjayBmcm9t
IGtlcm5lbCBtYWludGFpbmVycw0KdmVyeSB3ZWxsIElNTy4gwqBNYWluIGFyZ3VtZW50IHRoZXJl
IHdhcyB0aGUgY29tcGlsZS10aW1lIG9wdGlvbiByYXRoZXINCnRoYW4gYWxsb3dpbmcgaXQgdG8g
YmUgaW4gcnVudGltZSBsaWtlIHRoaXMgb25lLg0KDQoNCkx1Y2FzIERlIE1hcmNoaQ==

Re: [PATCH] modprobe: install default configuration

[Lubomir Rintel]

On Wed, 2016-03-02 at 16:07 +0000, De Marchi, Lucas wrote:
> On Wed, 2016-03-02 at 16:55 +0100, Marco d'Itri wrote:
> > 
> > On Mar 02, Lubomir Rintel <lkundrak@v3.sk> wrote:
> > 
> > > 
> > > 
> > > The kernel maintainers seem opposed to fixing this in kernel
> > > (despite a similar
> > > thing has been done with loop block devices) [1]. Let's fix this
> > > my
> > > overriding the
> > > defaults from userspace.
> > Because, guess what? This breaks userspace.
> > Feel free to configure your system this way if it is what you want.
> More context: https://github.com/systemd/systemd/pull/2778
> 
> Marco, could you be more specific on how this breaks userspace? It
> seems already pretty much broken to me. We can even argue if people
> wants the broken system back they can equally well configure their
> system to do that (even putting on /etc to override what was set on
> /usr/lib).
> 
> The commit message doesn't reflect the feedback from kernel
> maintainers
> very well IMO.  Main argument there was the compile-time option
> rather
> than allowing it to be in runtime like this one.

I thought that this part of feedback was a bit uninformed or there has
been some misunderstanding (perhaps on my side). There already are
options; the kernel patch just changed defaults for the options -- not
hardcoding the values or anything like that; just allowing to choose
different defaults at compile time.

The point was that if the user merely does "make oldconfig" to update
his kernel configuration the behavior wouldn't change. Thus it would be
safe for anyone to install an new kernel on an old distro even if
they're relying on the ancient behavior.

On the other hand, it would still allow for behavior change on distro
upgrades. I'm assuming it's okay to do that -- far bigger changes
regularly occur and users of exotic interfaces often end up adjusting
their tooling on major upgrades.

To me, the important part of the netdev@ feedback is: this is
unnecessary in kernel since it could be equally well done in userspace.

> Lucas De Marchi

Lubo

Re: [PATCH] modprobe: install default configuration

[Marco d'Itri]

On Mar 02, "De Marchi, Lucas" <lucas.demarchi@intel.com> wrote:

> Marco, could you be more specific on how this breaks userspace? It
It breaks the expectation that loading the module will make dummy0 
appear.
But if there is an agreement that this should be changed then I believe
that it should be changed in the kernel to be sure to have the same 
default across different distributions.

-- 
ciao,
Marco

Re: [PATCH] modprobe: install default configuration

[Lucas De Marchi]

On Wed, Mar 2, 2016 at 1:28 PM, Lubomir Rintel <lkundrak@v3.sk> wrote:
> On Wed, 2016-03-02 at 16:07 +0000, De Marchi, Lucas wrote:
>> On Wed, 2016-03-02 at 16:55 +0100, Marco d'Itri wrote:
>> >
>> > On Mar 02, Lubomir Rintel <lkundrak@v3.sk> wrote:
>> >
>> > >
>> > >
>> > > The kernel maintainers seem opposed to fixing this in kernel
>> > > (despite a similar
>> > > thing has been done with loop block devices) [1]. Let's fix this
>> > > my
>> > > overriding the
>> > > defaults from userspace.
>> > Because, guess what? This breaks userspace.
>> > Feel free to configure your system this way if it is what you want.
>> More context: https://github.com/systemd/systemd/pull/2778
>>
>> Marco, could you be more specific on how this breaks userspace? It
>> seems already pretty much broken to me. We can even argue if people
>> wants the broken system back they can equally well configure their
>> system to do that (even putting on /etc to override what was set on
>> /usr/lib).
>>
>> The commit message doesn't reflect the feedback from kernel
>> maintainers
>> very well IMO.  Main argument there was the compile-time option
>> rather
>> than allowing it to be in runtime like this one.
>
> I thought that this part of feedback was a bit uninformed or there has
> been some misunderstanding (perhaps on my side). There already are
> options; the kernel patch just changed defaults for the options -- not
> hardcoding the values or anything like that; just allowing to choose
> different defaults at compile time.
>
> The point was that if the user merely does "make oldconfig" to update
> his kernel configuration the behavior wouldn't change. Thus it would be
> safe for anyone to install an new kernel on an old distro even if
> they're relying on the ancient behavior.
>
> On the other hand, it would still allow for behavior change on distro
> upgrades. I'm assuming it's okay to do that -- far bigger changes
> regularly occur and users of exotic interfaces often end up adjusting
> their tooling on major upgrades.

I would say the better patch to the kernel would be to bite the bullet
and change the default.
The default is bad as shown by your example and people complaining
about the behavior. With a patch to kmod we are acknowledging the
default is bad and changing it, just like we would be if the patch to
the kernel was applied (i.e. people wanting the old behavior back
would have to change the option in kernel cmdline or /etc/modprobe.d)

Anyway, I don't oppose to applying it here, but I'll wait some more
days for people to chime in.

Thanks
Lucas De Marchi

Re: [PATCH] modprobe: install default configuration

[Lucas De Marchi]

On Wed, Mar 2, 2016 at 2:10 PM, Marco d'Itri <md@linux.it> wrote:
> On Mar 02, "De Marchi, Lucas" <lucas.demarchi@intel.com> wrote:
>
>> Marco, could you be more specific on how this breaks userspace? It
> It breaks the expectation that loading the module will make dummy0
> appear.
> But if there is an agreement that this should be changed then I believe
> that it should be changed in the kernel to be sure to have the same
> default across different distributions.

I fear that due to the problem with make oldconfig not changing the
behavior it's easier to have the same default across distros by
changing it here than by changing it in the kernel.

Lucas De Marchi

Re: [PATCH] modprobe: install default configuration

[Lubomir Rintel]

On Fri, 2016-03-04 at 02:02 -0300, Lucas De Marchi wrote:
> On Wed, Mar 2, 2016 at 1:28 PM, Lubomir Rintel <lkundrak@v3.sk>
> wrote:
> >=20
> > On Wed, 2016-03-02 at 16:07 +0000, De Marchi, Lucas wrote:
> > >=20
> > > On Wed, 2016-03-02 at 16:55 +0100, Marco d'Itri wrote:
> > > >=20
> > > >=20
> > > > On Mar 02, Lubomir Rintel <lkundrak@v3.sk> wrote:
> > > >=20
> > > > >=20
> > > > >=20
> > > > >=20
> > > > > The kernel maintainers seem opposed to fixing this in kernel
> > > > > (despite a similar
> > > > > thing has been done with loop block devices) [1]. Let's fix
> > > > > this
> > > > > my
> > > > > overriding the
> > > > > defaults from userspace.
> > > > Because, guess what? This breaks userspace.
> > > > Feel free to configure your system this way if it is what you
> > > > want.
> > > More context: https://github.com/systemd/systemd/pull/2778
> > >=20
> > > Marco, could you be more specific on how this breaks userspace?
> > > It
> > > seems already pretty much broken to me. We can even argue if
> > > people
> > > wants the broken system back they can equally well configure
> > > their
> > > system to do that (even putting on /etc to override what was set
> > > on
> > > /usr/lib).
> > >=20
> > > The commit message doesn't reflect the feedback from kernel
> > > maintainers
> > > very well IMO.=C2=A0=C2=A0Main argument there was the compile-time =
option
> > > rather
> > > than allowing it to be in runtime like this one.
> > I thought that this part of feedback was a bit uninformed or there
> > has
> > been some misunderstanding (perhaps on my side). There already are
> > options; the kernel patch just changed defaults for the options --
> > not
> > hardcoding the values or anything like that; just allowing to
> > choose
> > different defaults at compile time.
> >=20
> > The point was that if the user merely does "make oldconfig" to
> > update
> > his kernel configuration the behavior wouldn't change. Thus it
> > would be
> > safe for anyone to install an new kernel on an old distro even if
> > they're relying on the ancient behavior.
> >=20
> > On the other hand, it would still allow for behavior change on
> > distro
> > upgrades. I'm assuming it's okay to do that -- far bigger changes
> > regularly occur and users of exotic interfaces often end up
> > adjusting
> > their tooling on major upgrades.
> I would say the better patch to the kernel would be to bite the
> bullet
> and change the default.
> The default is bad as shown by your example and people complaining
> about the behavior. With a patch to kmod we are acknowledging the
> default is bad and changing it, just like we would be if the patch to
> the kernel was applied (i.e. people wanting the old behavior back
> would have to change the option in kernel cmdline or /etc/modprobe.d)
>=20
> Anyway, I don't oppose to applying it here, but I'll wait some more
> days for people to chime in.

Hi, I'm wondering if this could be moved forwards or needs some more
discussion/work?

Thanks,
Lubo

Re: [PATCH] modprobe: install default configuration

[Lucas De Marchi]

On Tue, Mar 29, 2016 at 7:27 AM, Lubomir Rintel <lkundrak@v3.sk> wrote:
> On Fri, 2016-03-04 at 02:02 -0300, Lucas De Marchi wrote:
>> On Wed, Mar 2, 2016 at 1:28 PM, Lubomir Rintel <lkundrak@v3.sk>
>> wrote:
>> >
>> > On Wed, 2016-03-02 at 16:07 +0000, De Marchi, Lucas wrote:
>> > >
>> > > On Wed, 2016-03-02 at 16:55 +0100, Marco d'Itri wrote:
>> > > >
>> > > >
>> > > > On Mar 02, Lubomir Rintel <lkundrak@v3.sk> wrote:
>> > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > The kernel maintainers seem opposed to fixing this in kernel
>> > > > > (despite a similar
>> > > > > thing has been done with loop block devices) [1]. Let's fix
>> > > > > this
>> > > > > my
>> > > > > overriding the
>> > > > > defaults from userspace.
>> > > > Because, guess what? This breaks userspace.
>> > > > Feel free to configure your system this way if it is what you
>> > > > want.
>> > > More context: https://github.com/systemd/systemd/pull/2778
>> > >
>> > > Marco, could you be more specific on how this breaks userspace?
>> > > It
>> > > seems already pretty much broken to me. We can even argue if
>> > > people
>> > > wants the broken system back they can equally well configure
>> > > their
>> > > system to do that (even putting on /etc to override what was set
>> > > on
>> > > /usr/lib).
>> > >
>> > > The commit message doesn't reflect the feedback from kernel
>> > > maintainers
>> > > very well IMO.  Main argument there was the compile-time option
>> > > rather
>> > > than allowing it to be in runtime like this one.
>> > I thought that this part of feedback was a bit uninformed or there
>> > has
>> > been some misunderstanding (perhaps on my side). There already are
>> > options; the kernel patch just changed defaults for the options --
>> > not
>> > hardcoding the values or anything like that; just allowing to
>> > choose
>> > different defaults at compile time.
>> >
>> > The point was that if the user merely does "make oldconfig" to
>> > update
>> > his kernel configuration the behavior wouldn't change. Thus it
>> > would be
>> > safe for anyone to install an new kernel on an old distro even if
>> > they're relying on the ancient behavior.
>> >
>> > On the other hand, it would still allow for behavior change on
>> > distro
>> > upgrades. I'm assuming it's okay to do that -- far bigger changes
>> > regularly occur and users of exotic interfaces often end up
>> > adjusting
>> > their tooling on major upgrades.
>> I would say the better patch to the kernel would be to bite the
>> bullet
>> and change the default.
>> The default is bad as shown by your example and people complaining
>> about the behavior. With a patch to kmod we are acknowledging the
>> default is bad and changing it, just like we would be if the patch to
>> the kernel was applied (i.e. people wanting the old behavior back
>> would have to change the option in kernel cmdline or /etc/modprobe.d)
>>
>> Anyway, I don't oppose to applying it here, but I'll wait some more
>> days for people to chime in.
>
> Hi, I'm wondering if this could be moved forwards or needs some more
> discussion/work?

Maybe getting an ack from kernel people involved since we still got no
feedback. Unfortunately our archives vanished and would be hard to
point them to the whole thread. Do you want to CC them here?


Lucas De Marchi

Re: [PATCH] modprobe: install default configuration

[Lubomir Rintel]

On Wed, 2016-04-13 at 01:11 -0300, Lucas De Marchi wrote:
> On Tue, Mar 29, 2016 at 7:27 AM, Lubomir Rintel <lkundrak@v3.sk>
> wrote:
> >=20
> > On Fri, 2016-03-04 at 02:02 -0300, Lucas De Marchi wrote:
> > >=20
> > > On Wed, Mar 2, 2016 at 1:28 PM, Lubomir Rintel <lkundrak@v3.sk>
> > > wrote:
> > > >=20
> > > >=20
> > > > On Wed, 2016-03-02 at 16:07 +0000, De Marchi, Lucas wrote:
> > > > >=20
> > > > >=20
> > > > > On Wed, 2016-03-02 at 16:55 +0100, Marco d'Itri wrote:
> > > > > >=20
> > > > > >=20
> > > > > >=20
> > > > > > On Mar 02, Lubomir Rintel <lkundrak@v3.sk> wrote:
> > > > > >=20
> > > > > > >=20
> > > > > > >=20
> > > > > > >=20
> > > > > > >=20
> > > > > > > The kernel maintainers seem opposed to fixing this in
> > > > > > > kernel
> > > > > > > (despite a similar
> > > > > > > thing has been done with loop block devices) [1]. Let's
> > > > > > > fix
> > > > > > > this
> > > > > > > my
> > > > > > > overriding the
> > > > > > > defaults from userspace.
> > > > > > Because, guess what? This breaks userspace.
> > > > > > Feel free to configure your system this way if it is what
> > > > > > you
> > > > > > want.
> > > > > More context: https://github.com/systemd/systemd/pull/2778
> > > > >=20
> > > > > Marco, could you be more specific on how this breaks
> > > > > userspace?
> > > > > It
> > > > > seems already pretty much broken to me. We can even argue if
> > > > > people
> > > > > wants the broken system back they can equally well configure
> > > > > their
> > > > > system to do that (even putting on /etc to override what was
> > > > > set
> > > > > on
> > > > > /usr/lib).
> > > > >=20
> > > > > The commit message doesn't reflect the feedback from kernel
> > > > > maintainers
> > > > > very well IMO.=C2=A0=C2=A0Main argument there was the compile-t=
ime
> > > > > option
> > > > > rather
> > > > > than allowing it to be in runtime like this one.
> > > > I thought that this part of feedback was a bit uninformed or
> > > > there
> > > > has
> > > > been some misunderstanding (perhaps on my side). There already
> > > > are
> > > > options; the kernel patch just changed defaults for the options
> > > > --
> > > > not
> > > > hardcoding the values or anything like that; just allowing to
> > > > choose
> > > > different defaults at compile time.
> > > >=20
> > > > The point was that if the user merely does "make oldconfig" to
> > > > update
> > > > his kernel configuration the behavior wouldn't change. Thus it
> > > > would be
> > > > safe for anyone to install an new kernel on an old distro even
> > > > if
> > > > they're relying on the ancient behavior.
> > > >=20
> > > > On the other hand, it would still allow for behavior change on
> > > > distro
> > > > upgrades. I'm assuming it's okay to do that -- far bigger
> > > > changes
> > > > regularly occur and users of exotic interfaces often end up
> > > > adjusting
> > > > their tooling on major upgrades.
> > > I would say the better patch to the kernel would be to bite the
> > > bullet
> > > and change the default.
> > > The default is bad as shown by your example and people
> > > complaining
> > > about the behavior. With a patch to kmod we are acknowledging the
> > > default is bad and changing it, just like we would be if the
> > > patch to
> > > the kernel was applied (i.e. people wanting the old behavior back
> > > would have to change the option in kernel cmdline or
> > > /etc/modprobe.d)
> > >=20
> > > Anyway, I don't oppose to applying it here, but I'll wait some
> > > more
> > > days for people to chime in.
> > Hi, I'm wondering if this could be moved forwards or needs some
> > more
> > discussion/work?
> Maybe getting an ack from kernel people involved since we still got
> no
> feedback. Unfortunately our archives vanished and would be hard to
> point them to the whole thread. Do you want to CC them here?

Sorry for the late reply; I'm not sure whom to include; you probably
have a better idea. Please feel free to CC whoever might be interested
in providing feedback to this.

> Lucas De Marchi

Lubo

Re: [PATCH] modprobe: install default configuration

[Lucas De Marchi]

CC'ing lkml and Rusty to get opinions on this.

On Sat, Apr 23, 2016 at 3:18 PM, Lubomir Rintel <lkundrak@v3.sk> wrote:
> On Wed, 2016-04-13 at 01:11 -0300, Lucas De Marchi wrote:
>> On Tue, Mar 29, 2016 at 7:27 AM, Lubomir Rintel <lkundrak@v3.sk>
>> wrote:
>> >
>> > On Fri, 2016-03-04 at 02:02 -0300, Lucas De Marchi wrote:
>> > >
>> > > On Wed, Mar 2, 2016 at 1:28 PM, Lubomir Rintel <lkundrak@v3.sk>
>> > > wrote:
>> > > >
>> > > >
>> > > > On Wed, 2016-03-02 at 16:07 +0000, De Marchi, Lucas wrote:
>> > > > >
>> > > > >
>> > > > > On Wed, 2016-03-02 at 16:55 +0100, Marco d'Itri wrote:
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > On Mar 02, Lubomir Rintel <lkundrak@v3.sk> wrote:
>> > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > The kernel maintainers seem opposed to fixing this in
>> > > > > > > kernel
>> > > > > > > (despite a similar
>> > > > > > > thing has been done with loop block devices) [1]. Let's
>> > > > > > > fix
>> > > > > > > this
>> > > > > > > my
>> > > > > > > overriding the
>> > > > > > > defaults from userspace.
>> > > > > > Because, guess what? This breaks userspace.
>> > > > > > Feel free to configure your system this way if it is what
>> > > > > > you
>> > > > > > want.
>> > > > > More context: https://github.com/systemd/systemd/pull/2778
>> > > > >
>> > > > > Marco, could you be more specific on how this breaks
>> > > > > userspace?
>> > > > > It
>> > > > > seems already pretty much broken to me. We can even argue if
>> > > > > people
>> > > > > wants the broken system back they can equally well configure
>> > > > > their
>> > > > > system to do that (even putting on /etc to override what was
>> > > > > set
>> > > > > on
>> > > > > /usr/lib).
>> > > > >
>> > > > > The commit message doesn't reflect the feedback from kernel
>> > > > > maintainers
>> > > > > very well IMO.  Main argument there was the compile-time
>> > > > > option
>> > > > > rather
>> > > > > than allowing it to be in runtime like this one.
>> > > > I thought that this part of feedback was a bit uninformed or
>> > > > there
>> > > > has
>> > > > been some misunderstanding (perhaps on my side). There already
>> > > > are
>> > > > options; the kernel patch just changed defaults for the options
>> > > > --
>> > > > not
>> > > > hardcoding the values or anything like that; just allowing to
>> > > > choose
>> > > > different defaults at compile time.
>> > > >
>> > > > The point was that if the user merely does "make oldconfig" to
>> > > > update
>> > > > his kernel configuration the behavior wouldn't change. Thus it
>> > > > would be
>> > > > safe for anyone to install an new kernel on an old distro even
>> > > > if
>> > > > they're relying on the ancient behavior.
>> > > >
>> > > > On the other hand, it would still allow for behavior change on
>> > > > distro
>> > > > upgrades. I'm assuming it's okay to do that -- far bigger
>> > > > changes
>> > > > regularly occur and users of exotic interfaces often end up
>> > > > adjusting
>> > > > their tooling on major upgrades.
>> > > I would say the better patch to the kernel would be to bite the
>> > > bullet
>> > > and change the default.
>> > > The default is bad as shown by your example and people
>> > > complaining
>> > > about the behavior. With a patch to kmod we are acknowledging the
>> > > default is bad and changing it, just like we would be if the
>> > > patch to
>> > > the kernel was applied (i.e. people wanting the old behavior back
>> > > would have to change the option in kernel cmdline or
>> > > /etc/modprobe.d)
>> > >
>> > > Anyway, I don't oppose to applying it here, but I'll wait some
>> > > more
>> > > days for people to chime in.
>> > Hi, I'm wondering if this could be moved forwards or needs some
>> > more
>> > discussion/work?
>> Maybe getting an ack from kernel people involved since we still got
>> no
>> feedback. Unfortunately our archives vanished and would be hard to
>> point them to the whole thread. Do you want to CC them here?
>
> Sorry for the late reply; I'm not sure whom to include; you probably
> have a better idea. Please feel free to CC whoever might be interested
> in providing feedback to this.

So in the intention of getting this patch going, I gave it some tests.
First, just mentioning you added all the network-related modules to
the same file.  A distro can change the default by not shipping the
file and the user can override it by having a file with the same name
on /etc (or /run). However if the user overrides a file this way, all
the content would need to be copied if he wants to change the options
for just one module.

Adding another file with another name doesn't really work:  the
configuration files are sorted alphabetically so there could be 2
scenarios: options are _added_ either before or after the default
options given by distro.  The kernel doesn't dictate what happens if
you provide the same option multiple times, but AFAICS it calls the
set function for each of them - this may or may not work.

I think that in order to get this patch applied we need to provide a
better way to allow distro and user to opt out: one idea would be to
add another keyword to the configuration file to allow people to
_override_ options rather than add new ones. In this case the user
would have to name the file to be loaded after the others, something
like 99-override-xyz.conf. Something like below

/usr/lib/modprobe.d/50-defaults.conf
        options foo paramfoo=1
        options bar paramfoo2=1

/etc/modprobe.d/99-test.conf
        options foo paramfoo=2

`modprobe foo' would mean the options are passed as `paramfoo=1 paramfoo=2'

If we have something like "options-override":

/etc/modprobe.d/99-test.conf
        options-override foo paramfoo=2

`modprobe foo' would mean the options are passed as `paramfoo=2'

Or we could add an "options-erase <modulename>" which just erases all
the options.


Thoughts?

-- 
Lucas De Marchi