Thread (22 messages) 22 messages, 8 authors, 2011-06-18

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

From: Neil Horman <nhorman@tuxdriver.com>
Date: 2011-05-25 15:02:02

On Wed, May 25, 2011 at 08:32:43PM +0800, Américo Wang wrote:
On Tue, May 24, 2011 at 11:03 PM, Andy Gospodarek [off-list ref] wrote:
quoted
On Tue, May 24, 2011 at 10:00:23PM +0800, Américo Wang wrote:
quoted
On Mon, May 23, 2011 at 11:13 PM, Andy Gospodarek [off-list ref] wrote:
quoted
On Mon, May 23, 2011 at 08:45:14PM +0800, Américo Wang wrote:
quoted
Hello, Jay, Andy,

Is there any peculiar reason that bonding code has to stay
in drivers/net/ directory?

Since bonding and bridge are somewhat similar, both of
which are used to "bond" two or more devices into one,
and bridge code is already in net/bridge/, so I think it also
makes sense to move bonding code into net/bonding/ too.

This could also help to grep the source more easily. :)

What do you think about the patch below?
(Note, this patch is against net-next-2.6.)
I would rather keep the code for bonding in drivers/net since it is
really a pure device (though not directly tied to any specific
hardware) rather than a device + forwarding or management code.
Is this a reason strong enough to leave it to drivers/net/ ?
I think it is generic enough to be moved to net/ directory... :-/
I think the distinction is an important one and is one of the main
reasons why I would like to see bonding stay in drivers/net.
Is this a rule that we judge if a piece of code should be in net/
or drivers/net/ ? For me, that big difference between these
two directory is clearly if the code is generic or hardware/platform
independent.
While thats a fine rule to draw a distinction on, it also creates other
organizational oddities.  By this reasoning, the loopback/tun-tap and xen
netfront drivers should also be moved to /net.  While this might be an ok move
to make, I think we can all agree, that while they don't touch specific
hardware, they implement instances of the driver model, and as such are
reasonably placed in /drivers.
quoted
quoted
quoted
It has bothered me for a long time that the code just to manage the VLAN
and bridge devices sits outside of drivers/net, but I've never proposed
a patch to move the files as I suspect the maintainers of that code
would like to keep it all together.  Maybe it is time to do that.
You mean move net/8021q/ to drivers/net/8021q/ ?
No.  I'm talking about the parts in the bridging and vlan code that
specifically setup devices, not all of the code.  I would be happier
if code that created objects of type net_device_ops all lived in
drivers/net.  Then all the drivers (real, stacked, or virtual) are in
the same place.
This would make grepping the source code more harder
than it is, at least now we can grepping all bridge source code
in net/bridge/, for example.
This is really a false assertion.  Theres nothing more or less hard about
finding bonding code in /drivers than there is in /net.  grep and find let you
locate the code in either place equally well, and cscope really makes it all
moot anyway.

Neil
Actually the vlan case you mentioned can be another example
to show that to moving bonding code into net/ makes sense.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help