Message-ID: <CAMuHMdXkGfXrjD-9yYpsp0sqsdEMNxKHDNnJ8=rKJ-mtEL+QkA@mail.gmail.com>
Date:	Mon, 11 Jul 2011 11:51:33 +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 11:39, Jeff Kirsher <jeffrey.t.kirsher@...el.com> wrote:
> On Sun, 2011-07-10 at 23:33 -0700, Geert Uytterhoeven wrote:
>> 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.
>
> It may just be me, these statements seem negative and bitter and is not
> helping us "solve" the issue.  While the statements may be true,  I
> would like to try and find a solution, what ever it may be, to better
> organize drivers/net/ethernet/ drivers to help with maintenance and
> future development.
>
>> > 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.
>
> I agree and understand, that is why I am taking the time to do it.  The
> drivers/net/ethernet/8390/, drivers/net/ethernet/tulip and
> drivers/net/ethernet/sun/ are some examples of this.

I have no problems with moving all 82596 drivers to drivers/net/ethernet/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