* [PATCH] modprobe: install default configuration @ 2016-03-02 15:18 Lubomir Rintel 2016-03-02 15:55 ` Marco d'Itri 0 siblings, 1 reply; 11+ messages in thread From: Lubomir Rintel @ 2016-03-02 15:18 UTC (permalink / raw) To: Lucas De Marchi; +Cc: linux-modules, 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 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH] modprobe: install default configuration 2016-03-02 15:18 [PATCH] modprobe: install default configuration Lubomir Rintel @ 2016-03-02 15:55 ` Marco d'Itri 2016-03-02 16:07 ` De Marchi, Lucas 0 siblings, 1 reply; 11+ messages in thread From: Marco d'Itri @ 2016-03-02 15:55 UTC (permalink / raw) To: Lubomir Rintel; +Cc: Lucas De Marchi, linux-modules [-- 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 --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] modprobe: install default configuration 2016-03-02 15:55 ` Marco d'Itri @ 2016-03-02 16:07 ` De Marchi, Lucas 2016-03-02 16:28 ` Lubomir Rintel 2016-03-02 17:10 ` Marco d'Itri 0 siblings, 2 replies; 11+ messages in thread From: De Marchi, Lucas @ 2016-03-02 16:07 UTC (permalink / raw) To: lkundrak, md; +Cc: linux-modules T24gV2VkLCAyMDE2LTAzLTAyIGF0IDE2OjU1ICswMTAwLCBNYXJjbyBkJ0l0cmkgd3JvdGU6DQo+ IE9uIE1hciAwMiwgTHVib21pciBSaW50ZWwgPGxrdW5kcmFrQHYzLnNrPiB3cm90ZToNCj4gDQo+ ID4gDQo+ID4gVGhlIGtlcm5lbCBtYWludGFpbmVycyBzZWVtIG9wcG9zZWQgdG8gZml4aW5nIHRo aXMgaW4ga2VybmVsDQo+ID4gKGRlc3BpdGUgYSBzaW1pbGFyDQo+ID4gdGhpbmcgaGFzIGJlZW4g ZG9uZSB3aXRoIGxvb3AgYmxvY2sgZGV2aWNlcykgWzFdLiBMZXQncyBmaXggdGhpcyBteQ0KPiA+ IG92ZXJyaWRpbmcgdGhlDQo+ID4gZGVmYXVsdHMgZnJvbSB1c2Vyc3BhY2UuDQo+IEJlY2F1c2Us IGd1ZXNzIHdoYXQ/IFRoaXMgYnJlYWtzIHVzZXJzcGFjZS4NCj4gRmVlbCBmcmVlIHRvIGNvbmZp Z3VyZSB5b3VyIHN5c3RlbSB0aGlzIHdheSBpZiBpdCBpcyB3aGF0IHlvdSB3YW50Lg0KDQpNb3Jl IGNvbnRleHQ6wqBodHRwczovL2dpdGh1Yi5jb20vc3lzdGVtZC9zeXN0ZW1kL3B1bGwvMjc3OA0K DQpNYXJjbywgY291bGQgeW91IGJlIG1vcmUgc3BlY2lmaWMgb24gaG93IHRoaXMgYnJlYWtzIHVz ZXJzcGFjZT8gSXQNCnNlZW1zIGFscmVhZHkgcHJldHR5IG11Y2ggYnJva2VuIHRvIG1lLiBXZSBj YW4gZXZlbiBhcmd1ZSBpZiBwZW9wbGUNCndhbnRzIHRoZSBicm9rZW4gc3lzdGVtIGJhY2sgdGhl eSBjYW4gZXF1YWxseSB3ZWxsIGNvbmZpZ3VyZSB0aGVpcg0Kc3lzdGVtIHRvIGRvIHRoYXQgKGV2 ZW4gcHV0dGluZyBvbiAvZXRjIHRvIG92ZXJyaWRlIHdoYXQgd2FzIHNldCBvbg0KL3Vzci9saWIp Lg0KDQpUaGUgY29tbWl0IG1lc3NhZ2UgZG9lc24ndCByZWZsZWN0IHRoZSBmZWVkYmFjayBmcm9t IGtlcm5lbCBtYWludGFpbmVycw0KdmVyeSB3ZWxsIElNTy4gwqBNYWluIGFyZ3VtZW50IHRoZXJl IHdhcyB0aGUgY29tcGlsZS10aW1lIG9wdGlvbiByYXRoZXINCnRoYW4gYWxsb3dpbmcgaXQgdG8g YmUgaW4gcnVudGltZSBsaWtlIHRoaXMgb25lLg0KDQoNCkx1Y2FzIERlIE1hcmNoaQ== ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] modprobe: install default configuration 2016-03-02 16:07 ` De Marchi, Lucas @ 2016-03-02 16:28 ` Lubomir Rintel 2016-03-04 5:02 ` Lucas De Marchi 2016-03-02 17:10 ` Marco d'Itri 1 sibling, 1 reply; 11+ messages in thread From: Lubomir Rintel @ 2016-03-02 16:28 UTC (permalink / raw) To: De Marchi, Lucas, md; +Cc: linux-modules 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] modprobe: install default configuration 2016-03-02 16:28 ` Lubomir Rintel @ 2016-03-04 5:02 ` Lucas De Marchi 2016-03-29 10:27 ` Lubomir Rintel 0 siblings, 1 reply; 11+ messages in thread From: Lucas De Marchi @ 2016-03-04 5:02 UTC (permalink / raw) To: Lubomir Rintel; +Cc: De Marchi, Lucas, md@Linux.IT, linux-modules 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] modprobe: install default configuration 2016-03-04 5:02 ` Lucas De Marchi @ 2016-03-29 10:27 ` Lubomir Rintel 2016-04-13 4:11 ` Lucas De Marchi 0 siblings, 1 reply; 11+ messages in thread From: Lubomir Rintel @ 2016-03-29 10:27 UTC (permalink / raw) To: Lucas De Marchi; +Cc: De Marchi, Lucas, md@Linux.IT, linux-modules 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] modprobe: install default configuration 2016-03-29 10:27 ` Lubomir Rintel @ 2016-04-13 4:11 ` Lucas De Marchi 2016-04-23 18:18 ` Lubomir Rintel 0 siblings, 1 reply; 11+ messages in thread From: Lucas De Marchi @ 2016-04-13 4:11 UTC (permalink / raw) To: Lubomir Rintel; +Cc: De Marchi, Lucas, md@Linux.IT, linux-modules 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] modprobe: install default configuration 2016-04-13 4:11 ` Lucas De Marchi @ 2016-04-23 18:18 ` Lubomir Rintel 2016-06-14 12:55 ` Lucas De Marchi 0 siblings, 1 reply; 11+ messages in thread From: Lubomir Rintel @ 2016-04-23 18:18 UTC (permalink / raw) To: Lucas De Marchi; +Cc: De Marchi, Lucas, md@Linux.IT, linux-modules 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] modprobe: install default configuration 2016-04-23 18:18 ` Lubomir Rintel @ 2016-06-14 12:55 ` Lucas De Marchi 0 siblings, 0 replies; 11+ messages in thread From: Lucas De Marchi @ 2016-06-14 12:55 UTC (permalink / raw) To: Lubomir Rintel Cc: De Marchi, Lucas, md@Linux.IT, linux-modules, lkml, Rusty Russell 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] modprobe: install default configuration 2016-03-02 16:07 ` De Marchi, Lucas 2016-03-02 16:28 ` Lubomir Rintel @ 2016-03-02 17:10 ` Marco d'Itri 2016-03-04 5:04 ` Lucas De Marchi 1 sibling, 1 reply; 11+ messages in thread From: Marco d'Itri @ 2016-03-02 17:10 UTC (permalink / raw) To: De Marchi, Lucas; +Cc: lkundrak, linux-modules 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] modprobe: install default configuration 2016-03-02 17:10 ` Marco d'Itri @ 2016-03-04 5:04 ` Lucas De Marchi 0 siblings, 0 replies; 11+ messages in thread From: Lucas De Marchi @ 2016-03-04 5:04 UTC (permalink / raw) To: De Marchi, Lucas, lkundrak, linux-modules 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2016-06-14 12:55 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-03-02 15:18 [PATCH] modprobe: install default configuration Lubomir Rintel 2016-03-02 15:55 ` Marco d'Itri 2016-03-02 16:07 ` De Marchi, Lucas 2016-03-02 16:28 ` Lubomir Rintel 2016-03-04 5:02 ` Lucas De Marchi 2016-03-29 10:27 ` Lubomir Rintel 2016-04-13 4:11 ` Lucas De Marchi 2016-04-23 18:18 ` Lubomir Rintel 2016-06-14 12:55 ` Lucas De Marchi 2016-03-02 17:10 ` Marco d'Itri 2016-03-04 5:04 ` Lucas De Marchi
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).