Date:	Thu, 26 May 2011 09:50:54 -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 Thu, May 26, 2011 at 05:32:08PM +0800, Américo Wang wrote:
> On Wed, May 25, 2011 at 11:20 PM, Neil Horman <nhorman@...driver.com> wrote:
> > 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*'
> 
> No, somone asked me why bonding is not in net/ and after some thinking,
> I see no reasons myself (thus sent this patch).
> 
"Why not" rarely seems like a good reason to change things 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.
> 
> Then I agree here.
> 
> >
> > 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
> >
> 
> Well, the problem is our code organisation, if we could organize the code
> in a better way that would help grepping the code.
> 
You've already demonstrated that its pretty easy.  Do we really need to cater to
someone who can't figure out to look for something in two possible places when
it will just cause confusion for those of us do.  And again, beyond that
tradeoff, I still don't see any advantage to doing this.

> >> 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?
> >
> 
> I don't think other drivers are supposed to use this function to register
> a packet handler, which is an important difference from my view.
> 
Note you just referred to the bridge/bond and vlan code as 'drivers' :).  And
why is that function the gating factor?  Why not register_netdev?  or
netif_receive_skb or dev_add_pack?  They all relate to the creation of device
interface and the reception of network data.

The fact is, bonding/bridging/vlans/tunnels/etc all have aspects that
make them more than just drivers.  They are where they are for a myrriad of
reasons.  Moving them around changes their location, but does _nothing_ about
the underlying fact that they're driver code plus other stuff, and as such
provides no real advantage in terms of organization.

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

Powered by blists - more mailing lists