netdev - Re: [RFC 43/72] a2065/ariadne: Move the a2065/ariadne drivers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1310345295.26989.76.camel@jtkirshe-mobl>
Date:	Sun, 10 Jul 2011 17:48:14 -0700
From:	Jeff Kirsher <jeffrey.t.kirsher@...el.com>
To:	Geert Uytterhoeven <geert@...ux-m68k.org>
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 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.

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?

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? 

> 
> > 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. 

Download attachment "signature.asc" of type "application/pgp-signature" (491 bytes)