[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1445336670.2246.11.camel@suse.com>
Date: Tue, 20 Oct 2015 12:24:30 +0200
From: Oliver Neukum <oneukum@...e.com>
To: Bjørn Mork <bjorn@...k.no>
Cc: davem@...emloft.net, netdev@...r.kernel.org
Subject: Re: [PATCH] usbnet: removed USB_USBNET as a config option
On Tue, 2015-10-20 at 10:43 +0200, Bjørn Mork wrote:
> Oliver Neukum <oneukum@...e.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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists