Re: [RFC] Summarizing deprecations

[Greg KH]

On Sat, May 31, 2014 at 04:56:34AM +0200, Sune Mølgaard wrote:
> Hi Greg, and thank you for correcting me!
> 
> Greg KH wrote:
> [snip]
> > Not true at all.
> 
> I trust you to know enough to be correct, but as we speak, I have at
> least 3 pieces of hardware, whose (out-of-tree) drivers regularly fail
> to compile come a new rc1. I usually manage to find or create a patch,
> but the breakage is usually due to months-old deprecations of system
> calls that finally (and understandably) where removed in those new rc1s.

What specific drivers are they?  Why are the drivers out of the tree?
I'll gladly add them to the drivers/staging/ directory as long as the
license of them allows me to do so.  That way api changes will happen
automatically for them.

> My experience is that vendors are not only blissfully aware of such
> changes until removal, but will generally only support final kernel
> versions - even if the deprecation/removal was announced several
> versions earlier.

In other words, no matter what we do, things outside of the kernel tree
will break.  This is on the vendor, not us now.  They know where to find
us, we have no idea who they are.

> > Have you looked at the kernel backport group and scripts?  They do much
> > of this already, automatically, backporting newer drivers to older
> > kernel versions for people stuck at those releases.  I think what you
> > want is already completed...
> 
> Whereas I thank you for those pointers, I now realize that I failed to
> mention a few crucial details.
> 
> My "knee-jerk" comment above was based on a rather important point that
> I failed to mention, namely that what I was talking about was drivers
> employing closed binary blobs, obviously and naturally precluding them
> from mainlining.

Then they are on their own as they are violating our license when
redistributing such a monstrosity.  They know the issues involved, and
are willing to pay the price to do such a thing.  There's nothing we can
do about them, sorry.  Go bug the vendor, not us.

And buy better hardware next time :)

greg k-h
--
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/