From: David Miller <davem@davemloft.net>
To: stephen@networkplumber.org
Cc: jhs@mojatatu.com, lkundrak@v3.sk, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] ifb: make device count build-time configurable
Date: Tue, 12 Jan 2016 15:54:40 -0500 (EST) [thread overview]
Message-ID: <20160112.155440.538873882796833417.davem@davemloft.net> (raw)
In-Reply-To: <20160112104437.0e1a841b@xeon-e3>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Tue, 12 Jan 2016 10:44:37 -0800
> On Tue, 12 Jan 2016 07:55:22 -0500
> Jamal Hadi Salim <jhs@mojatatu.com> wrote:
>
>> On 16-01-12 06:56 AM, Lubomir Rintel wrote:
>> > The devices can be created at run-time for quite some time already and the
>> > load-time device creation collides with attempts to create the device of
>> > the same name:
>> >
>> > # rmmod ifb
>> > # ip link add ifb0 type ifb
>> > RTNETLINK answers: File exists
>> >
>> > This is pretty much the same situation as was with the block loop devices
>> > which was solved by adding a build-time configuration that the
>> > distributions could use as they deem fit while keeping the default for
>> > compatibility.
>> >
>> > Let's do that here as well.
>> >
>> > Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
>>
>> I guess module options are frowned upon. so:
>
> I would prefer that this were done with a module parameter, the same as dummy.
> Only developers build their own configured kernels. Having the value set later
> at module load time is preferable.
I like this even less, it means tools behave significantly differently
based upon what module options were passed to the kernel.
Module options really should not change kernel behavior like this..
next prev parent reply other threads:[~2016-01-12 20:54 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-12 11:56 [PATCH 1/3] ifb: make device count build-time configurable Lubomir Rintel
2016-01-12 12:55 ` Jamal Hadi Salim
2016-01-12 18:44 ` Stephen Hemminger
2016-01-12 20:54 ` David Miller [this message]
2016-02-05 15:02 ` Lubomir Rintel
2016-01-12 15:10 ` Tom Gundersen
2016-01-12 15:19 ` Daniel Borkmann
2016-01-12 15:31 ` Lubomir Rintel
2016-01-12 15:36 ` [PATCH v2] " Lubomir Rintel
2016-01-12 20:42 ` David Miller
2016-01-12 15:35 ` [PATCH 1/3] " Daniel Borkmann
2016-01-12 15:43 ` Lubomir Rintel
2016-01-12 16:04 ` Daniel Borkmann
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=20160112.155440.538873882796833417.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=jhs@mojatatu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkundrak@v3.sk \
--cc=netdev@vger.kernel.org \
--cc=stephen@networkplumber.org \
/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).