Re: Feature Removals for 2.6.25

[Bill Davidsen]

Stephen Hemminger wrote:
> > > Ping?
> > > What:   sk98lin network driver
> > > When:   Feburary 2008
> > > Why:    In kernel tree version of driver is unmaintained. Sk98lin driver
> > > 	replaced by the skge driver. 
> > > Who:    Stephen Hemminger <shemminger@xxxxxxxxxxxxxxxxxxxx>
> > >
> > > ---------------------------
> > >       
> > We have been over this several times, and I thought someone had taken 
> > over the driver and was providing patches to put it in. Both skge and 
> > sky2 have been proposed as the replacement, people have reported 
> > problems with each. Suggest leaving this alone until the sk98lin 
> > actually needs work, then take it out. Problems in my problem system 
> > have been intermittent, take 4-40 hours to show and generate no errors, 
> > other than the driver thinks it's sending packets and the sniffer doesn't.
> >     
>
> The vendor sk98lin driver will continue it's happy life out of tree.
> The version in 2.6.25 is ancient and unmaintained and only supports older
> hardware. There are no outstanding issues with skge driver (sky2 is 
> prone to hardware problems, but then so is vendor driver).
>   

And those of us who are using it *have* old hardware. Old hardware that 
perhaps the people forcing other driver on us don't have.
> Unfortunately, removing sk98lin seems to be the only way to make die
> hard users report problems. The last time we removed it, some user's of
> old Genesis boards showed with issues, but those are now fixed.
>   

I guess I have a real problem with the "make die hard users report 
problems" thing, because it assumes that there is nothing wrong with 
*causing* us problems. Understand, this is not "change is bad" but 
"change is expensive." Because it means a change in kernel config, 
modules.conf, and possibly rc.local or initrd or similar. A per-machine 
effort which is small in ones, and large in sum.
> Jeff has scheduled sk98lin for removal in 2.6.26. (and it will probably 
> be gone from -mm before that). 
>
>   
If this were a case of the sk98lin driver needing work, I wouldn't be 
making the argument. But to make work for users in a case where there is 
no saving in effort for developers, sounds as if the developers place no 
value at all on the time of the people who build their own kernels, and 
if the vendors are good with it, that's all that matters.

Note that because the hardware is old, it's highly likely that most of 
it will be retired before that sk98lin driver needs a change. I can't 
see anyone using sk98lin on a new system, so it would be less 
contentious to let the hardware (or users) die of natural causes if you can.

--
Bill Davidsen <davidsen@xxxxxxx>
 "Woe unto the statesman who makes war without a reason that will still
 be valid when the war is over..." Otto von Bismark 


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