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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110525150144.GB11867@hmsreliant.think-freely.org>
Date:	Wed, 25 May 2011 11:01:44 -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:32:43PM +0800, Américo Wang wrote:
> On Tue, May 24, 2011 at 11:03 PM, Andy Gospodarek <andy@...yhouse.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@...yhouse.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@...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