[2.6 patch] schedule SHAPER for removal

[2.6 patch] schedule SHAPER for removal

[Adrian Bunk]

Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

This patch was already sent on:
- 13 Jan 2006

--- linux-2.6.15-mm3-full/Documentation/feature-removal-schedule.txt.old	2006-01-13 15:02:15.000000000 +0100
+++ linux-2.6.15-mm3-full/Documentation/feature-removal-schedule.txt	2006-01-13 15:06:19.000000000 +0100
@@ -164,0 +165,6 @@
+---------------------------
+
+What:   Traffic Shaper (CONFIG_SHAPER)
+When:   July 2006
+Why:    obsoleted by the code in net/sched/
+Who:    Adrian Bunk <bunk@stusta.de
--- linux-2.6.15-mm3-full/drivers/net/Kconfig.old	2006-01-13 15:06:34.000000000 +0100
+++ linux-2.6.15-mm3-full/drivers/net/Kconfig	2006-01-13 15:06:49.000000000 +0100
@@ -2663,7 +2663,7 @@
 	  "SCSI generic support".
 
 config SHAPER
-	tristate "Traffic Shaper (EXPERIMENTAL)"
+	tristate "Traffic Shaper (OBSOLETE)"
 	depends on EXPERIMENTAL
 	---help---
 	  The traffic shaper is a virtual network device that allows you to

Re: [2.6 patch] schedule SHAPER for removal

[Jan Engelhardt]

>Subject: [2.6 patch] schedule SHAPER for removal

Replaced by what; the QoS subsystem?


> config SHAPER
>-	tristate "Traffic Shaper (EXPERIMENTAL)"
>+	tristate "Traffic Shaper (OBSOLETE)"
> 	depends on EXPERIMENTAL


Jan Engelhardt
-- 
| Alphagate Systems, http://alphagate.hopto.org/
| jengelh's site, http://jengelh.hopto.org/

Re: [2.6 patch] schedule SHAPER for removal

[Benjamin LaHaise]

On Thu, Jan 19, 2006 at 03:11:50AM +0100, Adrian Bunk wrote:
> +What:   Traffic Shaper (CONFIG_SHAPER)
> +When:   July 2006
> +Why:    obsoleted by the code in net/sched/
> +Who:    Adrian Bunk <bunk@stusta.de

This length of obsolete cycles is way too short -- it's not even enough 
time for a single release of a distro to ship with the feature marked as 
obsolete.

		-ben

Re: [2.6 patch] schedule SHAPER for removal

[Adrian Bunk]

On Thu, Jan 19, 2006 at 04:57:22PM -0500, Benjamin LaHaise wrote:
> On Thu, Jan 19, 2006 at 03:11:50AM +0100, Adrian Bunk wrote:
> > +What:   Traffic Shaper (CONFIG_SHAPER)
> > +When:   July 2006
> > +Why:    obsoleted by the code in net/sched/
> > +Who:    Adrian Bunk <bunk@stusta.de
> 
> This length of obsolete cycles is way too short -- it's not even enough 
> time for a single release of a distro to ship with the feature marked as 
> obsolete.

Do we really have to wait the three years between stable Debian releases 
for removing an obsolete driver that has always been marked as 
EXPERIMENTAL?

Please be serious.

> 		-ben

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] schedule SHAPER for removal

[Benjamin LaHaise]

On Sat, Jan 21, 2006 at 01:48:48AM +0100, Adrian Bunk wrote:
> Do we really have to wait the three years between stable Debian releases 
> for removing an obsolete driver that has always been marked as 
> EXPERIMENTAL?
> 
> Please be serious.

I am completely serious.  The traditional cycle of obsolete code that works 
and is not causing a maintenence burden is 2 major releases -- one release 
during which the obsolete feature spews warnings on use, and another 
development cycle until it is actually removed.  That's at least 3 years, 
which is still pretty short compared to distro cycles.

There seems to be a lot of this disease of removing code for the sake of 
removal lately, and it's getting to the point of being really annoying.  If 
the maintainer of the code in question isn't pushing for its removal, I see 
no need to rush the process too much, especially when the affected users 
aren't even likely to see the feature being marked obsolete since they don't 
troll the source code looking for things that break setups.

		-ben

Re: [2.6 patch] schedule SHAPER for removal

[Adrian Bunk]

On Sun, Jan 22, 2006 at 12:47:07PM -0500, Benjamin LaHaise wrote:
> On Sat, Jan 21, 2006 at 01:48:48AM +0100, Adrian Bunk wrote:
> > Do we really have to wait the three years between stable Debian releases 
> > for removing an obsolete driver that has always been marked as 
> > EXPERIMENTAL?
> > 
> > Please be serious.
> 
> I am completely serious.  The traditional cycle of obsolete code that works 
> and is not causing a maintenence burden is 2 major releases -- one release 
> during which the obsolete feature spews warnings on use, and another 
> development cycle until it is actually removed.  That's at least 3 years, 
> which is still pretty short compared to distro cycles.
> 
> There seems to be a lot of this disease of removing code for the sake of 
> removal lately, and it's getting to the point of being really annoying.  If 
> the maintainer of the code in question isn't pushing for its removal, I see 
> no need to rush the process too much, especially when the affected users 
> aren't even likely to see the feature being marked obsolete since they don't 
> troll the source code looking for things that break setups.

The only supported combinations are distributions with the kernels they 
ship.

E.g. running Debian stable with any kernel > 2.6.8 is simply not 
supported.

The only point where users are supposed to see such changes are upgrades 
to new releases of their distribution - and this is anyways a point 
where you have to double-check whether it hadn't broken anything.

And the kernel isn't the main thing where things break during 
distribution upgrades - userspace breakages are much more common.

As an example, not so long ago an upgrade of the hdparm package on my 
Debian unstable system broke one local boot script I'm using because 
upstream removed the short form of an option.

And GNU make 3.81 will contain some backwards incompatible changes for 
being more POSIX compliant.

And many more changes I do not remember.

Distributions can document usespace-visible changes, but avoiding them 
is simply not possible.

> 		-ben

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] schedule SHAPER for removal

[Arjan van de Ven]

On Sun, 2006-01-22 at 19:20 +0100, Adrian Bunk wrote:
> On Sun, Jan 22, 2006 at 12:47:07PM -0500, Benjamin LaHaise wrote:
> > On Sat, Jan 21, 2006 at 01:48:48AM +0100, Adrian Bunk wrote:
> > > Do we really have to wait the three years between stable Debian releases 
> > > for removing an obsolete driver that has always been marked as 
> > > EXPERIMENTAL?
> > > 
> > > Please be serious.
> > 
> > I am completely serious.  The traditional cycle of obsolete code that works 
> > and is not causing a maintenence burden is 2 major releases -- one release 
> > during which the obsolete feature spews warnings on use, and another 
> > development cycle until it is actually removed.  That's at least 3 years, 
> > which is still pretty short compared to distro cycles.
> > 
> > There seems to be a lot of this disease of removing code for the sake of 
> > removal lately, and it's getting to the point of being really annoying.  If 
> > the maintainer of the code in question isn't pushing for its removal, I see 
> > no need to rush the process too much, especially when the affected users 
> > aren't even likely to see the feature being marked obsolete since they don't 
> > troll the source code looking for things that break setups.
> 
> The only supported combinations are distributions with the kernels they 
> ship.

I think you're being unreasonable here.

Removing unused code from the kernel, I'm all for that. Really.
But this is userspace visible functionality, and more care needs to be
taken than just adding a few lines to an obscure file in the kernel.
I agree with Ben that the kernel needs to printk a stern warning *AT USE
OF THE FEATURE* for at least a year before such a feature can be
removed. In addition I think that in case such a feature isn't actually
harmful of further development (for example, it could be because it's
fundamentally broken locking wise, or holding back major improvements)
then a longer period of warnings should be no problem. Together with
that should probably be something to ask distros to stop enabling the
feature asap, or at least communicate it as deprecated in their
respective release notes.

Re: [2.6 patch] schedule SHAPER for removal

[Dave Jones]

On Sun, Jan 22, 2006 at 07:32:56PM +0100, Arjan van de Ven wrote:

 > > The only supported combinations are distributions with the kernels they 
 > > ship.
 > 
 > I think you're being unreasonable here.

Absolutely. The statement is also completely false.
Fedora rebases to a new point release shortly after they become available
(in reality usually just after the .1 -stable release).
At least part of the reason is that with 3-4000 changes going in upstream
per release, the amount of work backporting fixes is just totally impractical.

I just looked over feature-removal-schedule.txt for things that are probably
going to impact us due to our rebasing.

The only thing there that could cause major heartburn for FC4 users is
Dominik's proposal to remove PCMCIA control ioctl (scheduled for Last November).

Migrating already working setups from pcmcia-cs to pcmcia-utils when an
update kernel gets pushed out gives me the creeps, especially as we're still
not at a state where 'everything works' in our FC5-development branch.
(I'd feel more comfortable retrofitting this after its been through a stable
 distro release and got a lot of exposure).
So if the old pcmcia code got ripped out in 2.6.17, chances are I'd carry
a 'revert this bunch of changes' patch for future FC4 updates.
Not that big a deal, but probably a days work to build & test,
plus ongoing maintainence to rediff the patch on future updates.

Pretty much everything else there is either only of impact to out-of-tree
modules, for which I couldn't really care less, or they're bits of functionality
that we have moved off already, or have disabled. (Though I'm not entirely
sure everything has moved off of V4L1 yet without going and checking)

 > In addition I think that in case such a feature isn't actually
 > harmful of further development (for example, it could be because it's
 > fundamentally broken locking wise, or holding back major improvements)
 > then a longer period of warnings should be no problem.  Together with
 > that should probably be something to ask distros to stop enabling the
 > feature asap, or at least communicate it as deprecated in their
 > respective release notes.

Sounds very practical, and something I'd be totally open to doing for Fedora.

		Dave

[2.6 patch] schedule SHAPER for removal

[Adrian Bunk]

On Wed, Jan 11, 2006 at 01:58:58AM +0000, Alan Cox wrote:
> On Mer, 2006-01-11 at 01:53 +0100, Andi Kleen wrote:
> > shaper is completely obsolete and it's probably best to just remove
> > all references to it and the kernel driver too.
> 
> I would agree with that but it nees to go through a proper obsolesence
> and obliteration cycle not just vanish.

Patch below.

cu
Adrian


<--  snip  -->


Signed-off-by: Adrian Bunk <bunk@stusta.de>

--- linux-2.6.15-mm3-full/Documentation/feature-removal-schedule.txt.old	2006-01-13 15:02:15.000000000 +0100
+++ linux-2.6.15-mm3-full/Documentation/feature-removal-schedule.txt	2006-01-13 15:06:19.000000000 +0100
@@ -164,0 +165,6 @@
+---------------------------
+
+What:   Traffic Shaper (CONFIG_SHAPER)
+When:   July 2006
+Why:    obsoleted by the code in net/sched/
+Who:    Adrian Bunk <bunk@stusta.de
--- linux-2.6.15-mm3-full/drivers/net/Kconfig.old	2006-01-13 15:06:34.000000000 +0100
+++ linux-2.6.15-mm3-full/drivers/net/Kconfig	2006-01-13 15:06:49.000000000 +0100
@@ -2663,7 +2663,7 @@
 	  "SCSI generic support".
 
 config SHAPER
-	tristate "Traffic Shaper (EXPERIMENTAL)"
+	tristate "Traffic Shaper (OBSOLETE)"
 	depends on EXPERIMENTAL
 	---help---
 	  The traffic shaper is a virtual network device that allows you to