Re: [RFC Patch] bonding: move to net/ directory

["Américo Wang" <xiyou.wangcong@gmail.com>]

On Wed, May 25, 2011 at 11:20 PM, Neil Horman <nhorman@tuxdriver.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@tuxdriver.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).


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

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