[RFC Patch] bonding: move to net/ directory

[RFC Patch] bonding: move to net/ directory

[Américo Wang]

[-- Attachment #1: Type: text/plain, Size: 663 bytes --]

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

Thanks!

Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com>
Cc:  "David Miller" <davem@davemloft.net>
Cc: Jay Vosburgh <fubar@us.ibm.com>
Cc: Andy Gospodarek <andy@greyhouse.net>

---

[-- Attachment #2: net-bonding-movement.diff --]
[-- Type: text/x-patch, Size: 6476 bytes --]

 Documentation/networking/bonding.txt        |    2 +-
 MAINTAINERS                                 |    2 +-
 drivers/net/Kconfig                         |   18 ------------------
 drivers/net/Makefile                        |    1 -
 net/Kconfig                                 |   19 +++++++++++++++++++
 net/Makefile                                |    1 +
 {drivers/net => net}/bonding/Makefile       |    0
 {drivers/net => net}/bonding/bond_3ad.c     |    0
 {drivers/net => net}/bonding/bond_3ad.h     |    0
 {drivers/net => net}/bonding/bond_alb.c     |    0
 {drivers/net => net}/bonding/bond_alb.h     |    0
 {drivers/net => net}/bonding/bond_debugfs.c |    0
 {drivers/net => net}/bonding/bond_ipv6.c    |    0
 {drivers/net => net}/bonding/bond_main.c    |    0
 {drivers/net => net}/bonding/bond_procfs.c  |    0
 {drivers/net => net}/bonding/bond_sysfs.c   |    0
 {drivers/net => net}/bonding/bonding.h      |    0
 17 files changed, 22 insertions(+), 21 deletions(-)

diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
index 1f45bd8..c1b3924 100644
--- a/Documentation/networking/bonding.txt
+++ b/Documentation/networking/bonding.txt
@@ -114,7 +114,7 @@ the following steps:
 -----------------------------------------------
 
 	The current version of the bonding driver is available in the
-drivers/net/bonding subdirectory of the most recent kernel source
+net/bonding subdirectory of the most recent kernel source
 (which is available on http://kernel.org).  Most users "rolling their
 own" will want to use the most recent kernel from kernel.org.
 
diff --git a/MAINTAINERS b/MAINTAINERS
index 49a0bf3..2eb2e79 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1495,7 +1495,7 @@ M:	Andy Gospodarek <andy@greyhouse.net>
 L:	netdev@vger.kernel.org
 W:	http://sourceforge.net/projects/bonding/
 S:	Supported
-F:	drivers/net/bonding/
+F:	net/bonding/
 F:	include/linux/if_bonding.h
 
 BROADCOM B44 10/100 ETHERNET DRIVER
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 19f04a3..a8d39e3 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -60,24 +60,6 @@ config DUMMY
 	  Instead of 'dummy', the devices will then be called 'dummy0',
 	  'dummy1' etc.
 
-config BONDING
-	tristate "Bonding driver support"
-	depends on INET
-	depends on IPV6 || IPV6=n
-	---help---
-	  Say 'Y' or 'M' if you wish to be able to 'bond' multiple Ethernet
-	  Channels together. This is called 'Etherchannel' by Cisco,
-	  'Trunking' by Sun, 802.3ad by the IEEE, and 'Bonding' in Linux.
-
-	  The driver supports multiple bonding modes to allow for both high
-	  performance and high availability operation.
-
-	  Refer to <file:Documentation/networking/bonding.txt> for more
-	  information.
-
-	  To compile this driver as a module, choose M here: the module
-	  will be called bonding.
-
 config MACVLAN
 	tristate "MAC-VLAN support (EXPERIMENTAL)"
 	depends on EXPERIMENTAL
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 209fbb7..6f1a3ca 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -25,7 +25,6 @@ obj-$(CONFIG_CHELSIO_T4) += cxgb4/
 obj-$(CONFIG_CHELSIO_T4VF) += cxgb4vf/
 obj-$(CONFIG_EHEA) += ehea/
 obj-$(CONFIG_CAN) += can/
-obj-$(CONFIG_BONDING) += bonding/
 obj-$(CONFIG_ATL1) += atlx/
 obj-$(CONFIG_ATL2) += atlx/
 obj-$(CONFIG_ATL1E) += atl1e/
diff --git a/net/Kconfig b/net/Kconfig
index 878151c..e963cde 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -191,6 +191,25 @@ source "net/bridge/netfilter/Kconfig"
 
 endif
 
+config BONDING
+	tristate "Bonding driver support"
+	depends on INET
+	depends on IPV6 || IPV6=n
+	---help---
+	  Say 'Y' or 'M' if you wish to be able to 'bond' multiple Ethernet
+	  Channels together. This is called 'Etherchannel' by Cisco,
+	  'Trunking' by Sun, 802.3ad by the IEEE, and 'Bonding' in Linux.
+
+	  The driver supports multiple bonding modes to allow for both high
+	  performance and high availability operation.
+
+	  Refer to <file:Documentation/networking/bonding.txt> for more
+	  information.
+
+	  To compile this driver as a module, choose M here: the module
+	  will be called bonding.
+
+
 source "net/dccp/Kconfig"
 source "net/sctp/Kconfig"
 source "net/rds/Kconfig"
diff --git a/net/Makefile b/net/Makefile
index a51d946..1e74030 100644
--- a/net/Makefile
+++ b/net/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_NET)		+= ipv6/
 obj-$(CONFIG_PACKET)		+= packet/
 obj-$(CONFIG_NET_KEY)		+= key/
 obj-$(CONFIG_BRIDGE)		+= bridge/
+obj-$(CONFIG_BONDING)		+= bonding/
 obj-$(CONFIG_NET_DSA)		+= dsa/
 obj-$(CONFIG_IPX)		+= ipx/
 obj-$(CONFIG_ATALK)		+= appletalk/
diff --git a/drivers/net/bonding/Makefile b/net/bonding/Makefile
similarity index 100%
rename from drivers/net/bonding/Makefile
rename to net/bonding/Makefile
diff --git a/drivers/net/bonding/bond_3ad.c b/net/bonding/bond_3ad.c
similarity index 100%
rename from drivers/net/bonding/bond_3ad.c
rename to net/bonding/bond_3ad.c
diff --git a/drivers/net/bonding/bond_3ad.h b/net/bonding/bond_3ad.h
similarity index 100%
rename from drivers/net/bonding/bond_3ad.h
rename to net/bonding/bond_3ad.h
diff --git a/drivers/net/bonding/bond_alb.c b/net/bonding/bond_alb.c
similarity index 100%
rename from drivers/net/bonding/bond_alb.c
rename to net/bonding/bond_alb.c
diff --git a/drivers/net/bonding/bond_alb.h b/net/bonding/bond_alb.h
similarity index 100%
rename from drivers/net/bonding/bond_alb.h
rename to net/bonding/bond_alb.h
diff --git a/drivers/net/bonding/bond_debugfs.c b/net/bonding/bond_debugfs.c
similarity index 100%
rename from drivers/net/bonding/bond_debugfs.c
rename to net/bonding/bond_debugfs.c
diff --git a/drivers/net/bonding/bond_ipv6.c b/net/bonding/bond_ipv6.c
similarity index 100%
rename from drivers/net/bonding/bond_ipv6.c
rename to net/bonding/bond_ipv6.c
diff --git a/drivers/net/bonding/bond_main.c b/net/bonding/bond_main.c
similarity index 100%
rename from drivers/net/bonding/bond_main.c
rename to net/bonding/bond_main.c
diff --git a/drivers/net/bonding/bond_procfs.c b/net/bonding/bond_procfs.c
similarity index 100%
rename from drivers/net/bonding/bond_procfs.c
rename to net/bonding/bond_procfs.c
diff --git a/drivers/net/bonding/bond_sysfs.c b/net/bonding/bond_sysfs.c
similarity index 100%
rename from drivers/net/bonding/bond_sysfs.c
rename to net/bonding/bond_sysfs.c
diff --git a/drivers/net/bonding/bonding.h b/net/bonding/bonding.h
similarity index 100%
rename from drivers/net/bonding/bonding.h
rename to net/bonding/bonding.h

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

[Andy Gospodarek]

On Mon, May 23, 2011 at 08:45:14PM +0800, Américo Wang wrote:
> 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.

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.

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

[Américo Wang]

On Mon, May 23, 2011 at 11:13 PM, Andy Gospodarek <andy@greyhouse.net> wrote:
> On Mon, May 23, 2011 at 08:45:14PM +0800, Américo Wang wrote:
>> 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... :-/

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

Thanks!

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

[Andy Gospodarek]

On Tue, May 24, 2011 at 10:00:23PM +0800, Américo Wang wrote:
> On Mon, May 23, 2011 at 11:13 PM, Andy Gospodarek <andy@greyhouse.net> wrote:
> > On Mon, May 23, 2011 at 08:45:14PM +0800, Américo Wang wrote:
> >> 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.

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

It has not bothered me enough to consider posting patches, but you
should consider it if it bothers you.

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

[Neil Horman]

On Tue, May 24, 2011 at 10:00:23PM +0800, Américo Wang wrote:
> On Mon, May 23, 2011 at 11:13 PM, Andy Gospodarek <andy@greyhouse.net> wrote:
> > On Mon, May 23, 2011 at 08:45:14PM +0800, Américo Wang wrote:
> >> 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... :-/
> 
> >
> > 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/ ?
> 
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. 

Neil

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

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

[Américo Wang]

On Tue, May 24, 2011 at 11:03 PM, Andy Gospodarek <andy@greyhouse.net> wrote:
> On Tue, May 24, 2011 at 10:00:23PM +0800, Américo Wang wrote:
>> On Mon, May 23, 2011 at 11:13 PM, Andy Gospodarek <andy@greyhouse.net> wrote:
>> > On Mon, May 23, 2011 at 08:45:14PM +0800, Américo Wang wrote:
>> >> 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.

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

Actually the vlan case you mentioned can be another example
to show that to moving bonding code into net/ makes sense.

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

[Américo Wang]

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.

The other similar thing is that pktgen is in net/core/ while netconsole is in
drivers/net/, which seems a little strange too.

vlan vs macvlan is the third example.

In short, there are three callers of netdev_rx_handler_register(), macvlan,
bonding and bridge, only bridge code stays in net/ directory.

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

[Neil Horman]

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 <andy@greyhouse.net> wrote:
> > On Tue, May 24, 2011 at 10:00:23PM +0800, Américo Wang wrote:
> >> On Mon, May 23, 2011 at 11:13 PM, Andy Gospodarek <andy@greyhouse.net> wrote:
> >> > On Mon, May 23, 2011 at 08:45:14PM +0800, Américo Wang wrote:
> >> >> 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.

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

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

[Neil Horman]

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

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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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

[Américo Wang]

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

Hmm, after reading Andy's comments again, I think his point is
probably bridge has STP management code which makes a difference
with bonding, but you know, we have 802.3ad in bonding too.

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

Sometimes cscope sucks, especially when you meet function pointers
which are pretty common in net code. When I grep netpoll code, I have to
do `grep ndo_netpoll_setup -nr net/  drivers/net`, if bonding were in net/
`grep -nr net/` is enough. 'netdev_rx_handler_register' too.

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

[Américo Wang]

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.

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

[Neil Horman]

On Thu, May 26, 2011 at 05:11:35PM +0800, Américo Wang wrote:
> On Wed, May 25, 2011 at 11:01 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> > 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.
> >
> 
> Hmm, after reading Andy's comments again, I think his point is
> probably bridge has STP management code which makes a difference
> with bonding, but you know, we have 802.3ad in bonding too.
> 
Ok, pppe, slip, localtalk and wireless have code that, strictly speaking have
non-driver code in them to, should they also be moved to /net? 

You seem stuck on this notion that theres a rule that squarely places code in
/net or /drivers.  Nominally the choice is obvious, but in several cases, such
as this, its simply not.  You have valid reasons for asserting bonding should be
in /net.  There are just as many that assert it should be in /drivers. 

> > 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.
> >
> 
> Sometimes cscope sucks, especially when you meet function pointers
> which are pretty common in net code. When I grep netpoll code, I have to
> do `grep ndo_netpoll_setup -nr net/  drivers/net`, if bonding were in net/
> `grep -nr net/` is enough. 'netdev_rx_handler_register' too.
> 
Yes, sometimes cscope sucks.  moving this code won't fix that.  And if the major
advantage to this move is that you can remove a directory from a grep command,
thats really no advantage at all.  To further illustrate this point, does the
fact that I could do this:
grep register_netdev\( -nr /drivers/net
instead of 
grep register_netdev\( -nr /net /drivers/net 
Justify the movement of the bridging code to /drivers?  Of course not.

Neil

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

[Neil Horman]

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@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).
> 
"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

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

[Michał Mirosław]

2011/5/26 Neil Horman <nhorman@tuxdriver.com>:
> On Thu, May 26, 2011 at 05:32:08PM +0800, Américo Wang wrote:
>> 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.

If you want to draw a line between net/ and drivers/net I propose
following idea:

net/ - everything that is about networking (or library for it) and
interacts only within the system (kernel<->user, or in-kernel)
drivers/net/ - everything that is a connecting point between the
system and external world - be it hardware, other VMs or hypervisor.

net/ would include wireless stack, all kinds of loopback devices,
tunnels (incl. vlan), bridging, bonding, tuntap, etc.
drivers/net/ would keep only what is hardware or external ABI dependent

Just my 2 cents (3 grosze ;-).

Best Regards,
Michał Mirosław

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

[Américo Wang]

2011/5/26 Michał Mirosław <mirqus@gmail.com>:
> 2011/5/26 Neil Horman <nhorman@tuxdriver.com>:
>> On Thu, May 26, 2011 at 05:32:08PM +0800, Américo Wang wrote:
>>> 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.
>
> If you want to draw a line between net/ and drivers/net I propose
> following idea:
>
> net/ - everything that is about networking (or library for it) and
> interacts only within the system (kernel<->user, or in-kernel)
> drivers/net/ - everything that is a connecting point between the
> system and external world - be it hardware, other VMs or hypervisor.
>
> net/ would include wireless stack, all kinds of loopback devices,
> tunnels (incl. vlan), bridging, bonding, tuntap, etc.
> drivers/net/ would keep only what is hardware or external ABI dependent
>

I agree with this, IMHO this would help to organize the code better.
And currently only tuntap and bonding are still in net/ directory.

In any aspects, now we are mixing net/ and drivers/net/ currently,
which could be improved.

Thanks!

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

[Joe Perches]

On Tue, 2011-06-07 at 00:34 +0800, Américo Wang wrote:
> I agree with this, IMHO this would help to organize the code better.
> And currently only tuntap and bonding are still in net/ directory.
> In any aspects, now we are mixing net/ and drivers/net/ currently,
> which could be improved.

There is a proposal to move some drivers/net content to
drivers/net/sw/

http://vger.kernel.org/netconf2010_slides/netconf-jtk.pdf

I think that'd be fine too.

I believe Jeff is going to submit patches soonish.

http://comments.gmane.org/gmane.linux.network/197232

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

[Eric Dumazet]

Le lundi 06 juin 2011 à 09:50 -0700, Joe Perches a écrit :
> On Tue, 2011-06-07 at 00:34 +0800, Américo Wang wrote:
> > I agree with this, IMHO this would help to organize the code better.
> > And currently only tuntap and bonding are still in net/ directory.
> > In any aspects, now we are mixing net/ and drivers/net/ currently,
> > which could be improved.
> 
> There is a proposal to move some drivers/net content to
> drivers/net/sw/
> 
> http://vger.kernel.org/netconf2010_slides/netconf-jtk.pdf
> 
> I think that'd be fine too.
> 
> I believe Jeff is going to submit patches soonish.
> 
> http://comments.gmane.org/gmane.linux.network/197232
> 

As long as the re-organization is done without loosing "git blame"
information on current files, I am fine.

If not, this is a showstopper and not worth the pain, exactly like other
cleanup patches.

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

[Joe Perches]

On Mon, 2011-06-06 at 19:04 +0200, Eric Dumazet wrote:
> Le lundi 06 juin 2011 à 09:50 -0700, Joe Perches a écrit :
> > There is a proposal to move some drivers/net content to
> > drivers/net/sw/
> > http://vger.kernel.org/netconf2010_slides/netconf-jtk.pdf
> > I think that'd be fine too.
> > I believe Jeff is going to submit patches soonish.
> > http://comments.gmane.org/gmane.linux.network/197232
> As long as the re-organization is done without loosing "git blame"
> information on current files, I am fine.
> If not, this is a showstopper and not worth the pain, exactly like other
> cleanup patches.

To preserve history, all of this should be done via:
	git mv oldpath/file newpath/file
	git commit -m newpath/file 
with some extra cleanups to Kconfig/Makefile files
so no worries.

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

[Jeff Kirsher]

[-- Attachment #1: Type: text/plain, Size: 949 bytes --]

On Mon, 2011-06-06 at 09:50 -0700, Joe Perches wrote:
> On Tue, 2011-06-07 at 00:34 +0800, Américo Wang wrote:
> > I agree with this, IMHO this would help to organize the code better.
> > And currently only tuntap and bonding are still in net/ directory.
> > In any aspects, now we are mixing net/ and drivers/net/ currently,
> > which could be improved.
> 
> There is a proposal to move some drivers/net content to
> drivers/net/sw/
> 
> http://vger.kernel.org/netconf2010_slides/netconf-jtk.pdf
> 
> I think that'd be fine too.
> 
> I believe Jeff is going to submit patches soonish.
> 
> http://comments.gmane.org/gmane.linux.network/197232
> 
> 

Correct, patches will be sent out here this week.

As far as moving tunap, bonding, etc into /drivers/net/sw that is the
eventual plan, but I have not done this work for this upcoming patchset.
I want to coordinate this work with Stephen Hemminger before I do any
moves.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Jeff Kirsher]

[-- Attachment #1: Type: text/plain, Size: 974 bytes --]

On Mon, 2011-06-06 at 10:20 -0700, Joe Perches wrote:
> On Mon, 2011-06-06 at 19:04 +0200, Eric Dumazet wrote:
> > Le lundi 06 juin 2011 à 09:50 -0700, Joe Perches a écrit :
> > > There is a proposal to move some drivers/net content to
> > > drivers/net/sw/
> > > http://vger.kernel.org/netconf2010_slides/netconf-jtk.pdf
> > > I think that'd be fine too.
> > > I believe Jeff is going to submit patches soonish.
> > > http://comments.gmane.org/gmane.linux.network/197232
> > As long as the re-organization is done without loosing "git blame"
> > information on current files, I am fine.
> > If not, this is a showstopper and not worth the pain, exactly like other
> > cleanup patches.
> 
> To preserve history, all of this should be done via:
> 	git mv oldpath/file newpath/file
> 	git commit -m newpath/file 
> with some extra cleanups to Kconfig/Makefile files
> so no worries.
> 
> 

Joe is right, and that is the method that I have been using.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Ben Hutchings]

On Mon, 2011-06-06 at 10:20 -0700, Joe Perches wrote:
> On Mon, 2011-06-06 at 19:04 +0200, Eric Dumazet wrote:
> > Le lundi 06 juin 2011 à 09:50 -0700, Joe Perches a écrit :
> > > There is a proposal to move some drivers/net content to
> > > drivers/net/sw/
> > > http://vger.kernel.org/netconf2010_slides/netconf-jtk.pdf
> > > I think that'd be fine too.
> > > I believe Jeff is going to submit patches soonish.
> > > http://comments.gmane.org/gmane.linux.network/197232
> > As long as the re-organization is done without loosing "git blame"
> > information on current files, I am fine.
> > If not, this is a showstopper and not worth the pain, exactly like other
> > cleanup patches.
> 
> To preserve history, all of this should be done via:
> 	git mv oldpath/file newpath/file
> 	git commit -m newpath/file 
> with some extra cleanups to Kconfig/Makefile files
> so no worries.

git doesn't explicitly record moves; it just recognises moves if you
tell it to look for them (e.g. 'git diff -M' and 'git log --follow').

'git mv' is essentially shorthand for mv && git add && git rm.  And
specifying the old or new path on the 'git commit' line is redundant,
because the changes are already in the index.

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

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

[WANG Cong]

On Mon, 06 Jun 2011 10:31:05 -0700, Jeff Kirsher wrote:

> On Mon, 2011-06-06 at 09:50 -0700, Joe Perches wrote:
>> On Tue, 2011-06-07 at 00:34 +0800, Américo Wang wrote:
>> > I agree with this, IMHO this would help to organize the code better.
>> > And currently only tuntap and bonding are still in net/ directory. In
>> > any aspects, now we are mixing net/ and drivers/net/ currently, which
>> > could be improved.
>> 
>> There is a proposal to move some drivers/net content to drivers/net/sw/
>> 
>> http://vger.kernel.org/netconf2010_slides/netconf-jtk.pdf
>> 
>> I think that'd be fine too.
>> 
>> I believe Jeff is going to submit patches soonish.
>> 
>> http://comments.gmane.org/gmane.linux.network/197232
>> 
>> 
>> 
> Correct, patches will be sent out here this week.
> 

But I still don't see them so far... :-/ Can you Cc me as well?

> As far as moving tunap, bonding, etc into /drivers/net/sw that is the
> eventual plan, but I have not done this work for this upcoming patchset.
> I want to coordinate this work with Stephen Hemminger before I do any
> moves.

Is net/bridge ==> drivers/net/sw/bridge in your plan too?