Message-ID: <CAMuHMdXfpbbfv7oT+0oDWJd0=x0BBqEeCcGWaxMHagTXoeCscQ@mail.gmail.com>
Date:	Mon, 11 Jul 2011 08:33:23 +0200
From:	Geert Uytterhoeven <geert@...ux-m68k.org>
To:	jeffrey.t.kirsher@...el.com
Cc:	"davem@...emloft.net" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [RFC 43/72] a2065/ariadne: Move the a2065/ariadne drivers

On Mon, Jul 11, 2011 at 02:48, Jeff Kirsher <jeffrey.t.kirsher@...el.com> wrote:
> On Sun, 2011-07-10 at 12:34 -0700, Geert Uytterhoeven wrote:
>> On Sat, Jul 9, 2011 at 16:30, Jeff Kirsher
>> <jeffrey.t.kirsher@...el.com> wrote:
>> > On Tue, 2011-06-28 at 13:33 -0700, Geert Uytterhoeven wrote:
>> >> And (in some other patch) 82596.c is an Intel driver, not a
>> Motorola driver.
>> >
>> > 82596.c is not an Intel driver, it is an Intel part.  The driver was
>>
>> Sorry, I meant "driver for an Intel part".
>>
>> > written and support by someone other than Intel.  I am looking at
>> how to
>>
>> Sure. But I'm strongly against classifying drivers based on who wrote
>> them ;-)
>
> I agree to some extent, because if that were the case, we would have a
> donald_becker/ directory for several of the drivers. :)
>
> Here is one of the problem's I keep running into and there is no simple
> answer.  While most of the drivers can be grouped together by the
> hardware they use, that does not work "logically" for every driver.
>
> In addition, if vendor 'A' makes a part and vendor 'B' uses same part in
> a device/system/NIC and vendor 'B' creates the driver, supports the
> driver and maintains the driver.  Should the part be categorized under
> vendor 'A'?  IMHO, I think it should be categorized as a vendor 'B'
> driver.

Several of the Ethernet drivers are of a third type: vendor A chip, vendor B
card, entity C software.

> I started this work with the idea of trying to organize the drivers in
> the same way that the drivers were to be in the Kconfig, which tended to
> be drivers/net/ethernet/<manufacturer>.
>
> One of the problems that arise in this organization is what do we do
> when vendor A is bought by vendor B, and vendor B takes on the support
> of all the old vendor A parts/drivers?

We don't care. We don't sort drivers by who support them. Eventually, vendors
lose interest and they all end up under "Linux kernel community" anyway.

> So I am open to suggestions.  The process I have using to organize the
> drivers has been to group drivers that use common libraries and/or code
> first, then group by either manufacturer, maintainer, or common
> platform.
>
> I would like to keep the lasi_82506.c, sni_82596.c, 82506.c and similar
> drivers out of the intel/ directory because we would not be supporting
> the drivers and they are not similar to our drivers that we do support
> that would be in the intel/ directory.
>
> Again, I open to suggestions on how to best organize these types of
> drivers.  Maybe create a misc/ or <bus_type>/ for these types of
> drivers?

"Similar" drivers should be together and consolidated (if someone has time
to do it). They can even be of different brands.
I.e. not all Tulip-compatibles were manufactured by Digital or Intel.

>> > better organize the 82596.c, lasi_82596.c, lib82596.c, and
>> sni_82596.c
>> > which all use an Intel Ethernet chip but were written and supported
>> by
>> > someone other than Intel.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
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