Date:	Wed, 25 May 2011 11:20:23 -0400
From:	Neil Horman <nhorman@...driver.com>
To:	Américo Wang <xiyou.wangcong@...il.com>
Cc:	Andy Gospodarek <andy@...yhouse.net>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	Jay Vosburgh <fubar@...ibm.com>
Subject: Re: [RFC Patch] bonding: move to net/ directory

On Wed, May 25, 2011 at 08:43:21PM +0800, Américo Wang wrote:
> On Wed, May 25, 2011 at 12:33 AM, Neil Horman <nhorman@...driver.com> wrote:
> > This all sounds like change for the sake of change to me.  I don't see any
> > compelling argument for moving bonding (or bridging or vlans, etc) around at
> > all.  All of these software drivers have feet in multple subsystems, but that
> > just means that theres not going to be a compelling argument to move them any
> > place,  at least not without an immediate subsequent argument that it really
> > belonged back where it was.  Unless you can show a solid benefit to moving the
> > code, I don't see why any reorganization is needed.
> 
> Well, as a people who worked on bonding code, I have no problem to know
> bonding code is under drivers/net/, but for people who don't know this, probably
> net/ is the first place they want to search.
> 
you've asked them?

cd git/net-next-2.6
find . -name '*bond*'

Thats going to find bonding code for you regardless of which place its in.  If
someone sufficiently unversed in working with a source tree goes looking for
some code by randomly poking around in directories, then they have bigger
problems than not finding what they want in the first place they look.  If thats
the only thing this move is meant to solve, it seems like a non-problem to me.

> The other similar thing is that pktgen is in net/core/ while netconsole is in
> drivers/net/, which seems a little strange too.
> 
Its is, and loopback is in /drivers/net, as is tun-tap and xen-netfront (none of
which touch actual hardware), as is slip and ppp, which are net drivers, but
only operate on non net hardware. ppoe is another example which operates on
ethernet, but sits on top of a secondary physical device (and so has no real
hardware itself).  These could all arguably be moved to /net, because they have
no real hardware, but are in drivers because they implement instances of the net
driver interface.

> vlan vs macvlan is the third example.
> 
yes, it is, macvlan, like you assert could be moved, but you could just as
easily move vlan to /drivers because it implements an instance of the net device
driver interface.

The bottom line is, sometimes things aren't black and white, they're gray. And
we put code where it makes the most sense at the time.  We move it when it
makes sense to, but I don't hear any compelling argument to make that move.
Yes, we're not always consistent with where we put hardwareless drivers, but to
make a policy and shove everything to one place or another doesn't any more
sense.  If we do that we either wind up with things that we think of as drivers
in the /net directory, or we wind up with stuff thats really protocol oriented
in the /drivers directory.  And if the major problem we solve by doing so is
making life easier for someone who otherwise wouldn't be able to find said code
with a quick grep or find operation, it really doesn't seem like its worthwhile
to me

> In short, there are three callers of netdev_rx_handler_register(), macvlan,
> bonding and bridge, only bridge code stays in net/ directory.
Why is calling netdev_rx_handler_register a gating factor here?

Neil

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