[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110524163323.GB28521@hmsreliant.think-freely.org>
Date: Tue, 24 May 2011 12:33:24 -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 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... :-/
>
> >
> > 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@...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
Powered by blists - more mailing lists