Message-Id: <1219212946.7591.303.camel@violet.holtmann.net>
Date:	Wed, 20 Aug 2008 08:15:46 +0200
From:	Marcel Holtmann <marcel@...tmann.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Evgeniy Polyakov <johnpol@....mipt.ru>,
	David Miller <davem@...emloft.net>, akpm@...ux-foundation.org,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT]: Networking

Hi Linus,

> > I belive it was you who told that there is no black and white (another 
> > guy told that there is no spoon, I frequntly confuse).
> 
> Yes.
> 
> > Any changes made no matter when can not be 100% tested in laboratory 
> > environment, even fixes, which look obviously.
> 
> 100% agreed.
> 
> Please note that I'm not against these things slipping in occasionally. 
> The reason I brought this up in the first place really wasn't the loopback 
> driver issue at all. The reason I brought it up was simply the fact that 
> when I compare the size and frequency of changes, the networking pulls 
> tend to be the worst of the lot of the "core" kernel changes.
> 
> I say "core" kernel changes, because things are usually worse for the 
> outliers. As mentioned, networking is actually one of the _better_ guys if 
> you start comparing to the DVB people, or to some of the architectures 
> that often slip the merge window _entirely_, and *all* their changes come 
> in during -rc2 or something.
> 
> So it's not that networking is especially bad on an absolute scale in this 
> regard. And it's not like it doesn't happen all the time for everybody 
> else too. But I think networking has ben a bit more cavalier about things 
> than many other core areas.

I was always under the impression that Dave was quite strict when it
comes to merging things after the merge window. Yes, some things should
have better waiting for the next release, but we always had exceptions
for various things that fall out of the merge window anyway.

All the small "soldiers" like me make a call on what to pick to send to
Dave and it is not that we try to sneak anything in. It just made sense
to us and either he agrees or not. Some choices are better than others,
no questions asked, but I think what you are seeing is that networking
is getting huge. And this is mostly networking drivers. And I don't
expect this to slow down or anything. The Linux WiFi support is just at
the edge to really become competitive and show real leading across all
other operating systems.

When looking at the actual split between net/ and drivers/, then the
drivers part is the big one. And I don't expect this to go down any time
soon. We are about to get Ultra-Wideband support merged. After that we
will have plain networking over UWB, Wireless USB using UWB and soon
Bluetooth over UWB. Also we will see Bluetooth over 802.11 and then
another Ultra-Low-Power thing for sensor devices. And I forget WiMAX.
That is just the short term wireless future. Every of these come with
new networking drivers and then you have new Ethernet drivers and so on.
It is just a lot of stuff.

While looking at the actual diffstat, I realized that I really was the
biggest offender:

net/bluetooth/hci_sysfs.c                   |  376 ++++++++++++++-------------

This is actually the regression fix. It is big, because thanks to sysfs,
I had to move some code around in that file and rename things. I should
have seen that earlier and gave Dave an extra comment why it is so big.
That was my bad. Sorry for that.

Regards

Marcel


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists