From: Oliver Neukum <oneukum@suse.com>
To: "Bjørn Mork" <bjorn@mork.no>
Cc: davem@davemloft.net, netdev@vger.kernel.org
Subject: Re: [PATCH] usbnet: removed USB_USBNET as a config option
Date: Tue, 20 Oct 2015 12:24:30 +0200 [thread overview]
Message-ID: <1445336670.2246.11.camel@suse.com> (raw)
In-Reply-To: <87k2qiszfv.fsf@nemi.mork.no>
On Tue, 2015-10-20 at 10:43 +0200, Bjørn Mork wrote:
> Oliver Neukum <oneukum@suse.com> writes:
> > On Mon, 2015-10-19 at 21:16 +0200, Bjørn Mork wrote:
> >
> >> This looks incomplete.
> >
> > Yes, it is against the earlier patch set which introduces the CDC
> > parser in cdc-acm and cdc-wdm. In hindsight I should have reversed
> > the order of patches.
>
> Ah, right, I see.
>
> But that patch has it's own set of problems, as pointed out by the test
> robot:
>
> All the USBNET based minidrivers (as well as the USB_USBNET
> infrastructure itself) are protected by
>
> menuconfig USB_NET_DRIVERS
> tristate "USB Network Adapters"
> default USB if USB
> depends on USB && NET
>
> if USB_NET_DRIVERS
> ..
>
>
> but USB_ACM and USB_WDM don't have similar protection. So you'll have
> to make them select NET and USB_NET_DRIVERS too.
I really would like to avoid that.
> Selecting NET is going to be messy. It already selects 3 other symbols,
> which you'll have to add as well. And I have a feeling that the list of
> NET dependencies might grow, which probably explains why there currently
> are no "select NET"'s in the kernel. So "select NET" is most likely out
> of the question. And I don't think we want to make USB_ACM or USB_WDM
> depend on NET either. It will not make sense to anyone attempting to
> select these drivers, resulting in infinite confusion.
Well, ACM is a tty driver which in theory makes sense without net,
so I think it would be wrong to demand networking support.
> So we might need to move cdc_parse_cdc_header() out of usbnet.c after
> all. Keeping it there creates an unnecessary "select" mess. But I don't
> know where to put it... Either a common CDC helper module or the USB
> core I guess.
A common module means that the overhead of a module would be incurred.
Do you have any other candidates that could go into a common helper
module?
> Sorry for not bringing this up earlier. I know you asked specifically
> about this. I obviously didn't think it thoroughly through before.
Neither did I.
Regards
Oliver
next prev parent reply other threads:[~2015-10-20 10:26 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-19 12:23 [PATCH] usbnet: removed USB_USBNET as a config option Oliver Neukum
2015-10-19 19:16 ` Bjørn Mork
2015-10-20 6:28 ` Oliver Neukum
2015-10-20 8:43 ` Bjørn Mork
2015-10-20 10:24 ` Oliver Neukum [this message]
2015-10-20 11:03 ` Bjørn Mork
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=1445336670.2246.11.camel@suse.com \
--to=oneukum@suse.com \
--cc=bjorn@mork.no \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.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).