Re: [RFC] Summarizing deprecations

[Sune Mølgaard]

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.

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.

[snip]
> It was a success.  Do you know of any hardware that Linux currently does
> not support that a vendor wants a Linux driver for it?  I do not.
> 
> If you do, send them to me, I'll be glad to work on it, much like all of
> the other drivers we have worked on in this program over the years.
> 
> Of course, if the vendor doesn't want a Linux driver for their hardware,
> well, there's nothing anyone of us can do about that.

My sincerest apologies for remembering the project incorrectly!

It was, as is apparent from your answer, about bringing Linux drivers
about for hardware that didn't have even an attempt at a Linux driver
beforehand, and I, mistakenly, remembered it as a completely different
offer.

Sorry for the confusion, and most well-deserved kudos for the success!

> 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.

Based as this is upon my personal experience, even if a vendor that does
provide an out-of-tree driver would like to mainline and get rid of the
binary blob, some components of their board may preclude them from doing
so. Case in point would be HighPoint, who provides a driver for the
consumer-level board that I own, and have been rather forthcoming with
regards to listening and responding to my gripes about their driver
failing to compile or function with newer kernels, but excuse themselves
for not going full OSS by demands from sub-vendors of particular chips.

nVidia is a whole other kettle of fish with them referring to a failure
of their driver on certain laptop configurations being due to a kernel
bug, even though at least some systems, including my own, works if one
updates a number of system calls in the open part of their driver to the
"new" call.

Still, I imagine that you recommendation for the backport group and
scripts means that they actually "scan" for such changes, and I shall
contact them shortly, but I wanted to clarify what I meant, and also
apologize for my misremembering the scope of the project that I referred to.
> 
> thanks,
> 
> greg k-h

My thanks as well,

Sune Mølgaard
--
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/