[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.1010290629450.25426@eddie.linux-mips.org>
Date: Fri, 29 Oct 2010 06:46:13 +0100 (BST)
From: "Maciej W. Rozycki" <macro@...ux-mips.org>
To: David Miller <davem@...emloft.net>
cc: paul.gortmaker@...driver.com, netdev@...r.kernel.org
Subject: Re: [PATCH 05/15] dec netdev: relocate DIGITAL based drivers to
legacy
On Fri, 29 Oct 2010, Maciej W. Rozycki wrote:
> > This is not about a specific bus technology, it's simply for
> > "really old stuff" so we can declutter the top-level of drivers/net
>
> Hmm, what's the difference between placing these drivers here or there
> and what's so particular about them that they cause clutter? I mean a
> mere high number of items does not cause a mess by itself -- the lack of
> order might.
I have given myself some food for thought and have come up with the
following proposal: how about simply classifying drivers according to the
physical layer they support or if multiple are, such as with the Ethernet
that is backwards compatible, the newest variation they do?
This would be no different to what we do wrt network protocols under
net/, so drivers would go to ethernet/, fasteth/, gbeth/, 10gbeth/, fddi/,
tokenring/, atm/, appletalk/, etc. (names up to debate if need be) as
applicable. This would scale well, avoid the need for arbitrary decisions
(is this piece legacy yet or not?) and automatically classify drivers as
more or less obsolescent too, as obviously none of the stuff under
ethernet/, fddi/ or tokenring/ can be reasonably recent unlike 10gbeth/.
Software stuff such as SLIP or PPP could go either into separate
subdirectories or grouped together under software/; I gather we have a few
such pieces only.
What do you think?
Maciej
--
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