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: <20110526133803.GA12617@hmsreliant.think-freely.org>
Date:	Thu, 26 May 2011 09:38:03 -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:11:35PM +0800, Américo Wang wrote:
> On Wed, May 25, 2011 at 11:01 PM, Neil Horman <nhorman@...driver.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
--
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