linux-modules.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lucas De Marchi <lucas.de.marchi@gmail.com>
To: Lubomir Rintel <lkundrak@v3.sk>
Cc: "De Marchi, Lucas" <lucas.demarchi@intel.com>,
	"md@Linux.IT" <md@linux.it>,
	"linux-modules@vger.kernel.org" <linux-modules@vger.kernel.org>
Subject: Re: [PATCH] modprobe: install default configuration
Date: Fri, 4 Mar 2016 02:02:49 -0300	[thread overview]
Message-ID: <CAKi4VA+B7YOpVV5ogUqx4HuL2re=C7D+1aaB_VRjP0F9tUNF6g@mail.gmail.com> (raw)
In-Reply-To: <1456936094.32064.40.camel@v3.sk>

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

  reply	other threads:[~2016-03-04  5:02 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKi4VA+B7YOpVV5ogUqx4HuL2re=C7D+1aaB_VRjP0F9tUNF6g@mail.gmail.com' \
    --to=lucas.de.marchi@gmail.com \
    --cc=linux-modules@vger.kernel.org \
    --cc=lkundrak@v3.sk \
    --cc=lucas.demarchi@intel.com \
    --cc=md@linux.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).