[RFC] Summarizing deprecations

[RFC] Summarizing deprecations

[Sune Mølgaard]

Dear list,

In order to keep this non-code RFC brief, allow me to list a few
observations and then a proposal, that I shall be happy to engage in,
but for which I'd like a bit of guidance:

1) System calls get superseded and deprecated on a regular basis
2) Keeping track of deprecations can be difficult
3) HW vendors with out-of-tree drivers allocate too few resources to
handle 1) and 2)
4) Out-of-tree drivers usually fail to take deprecations into
consideration, and then breaking when deprecation leads to removal

A knee-jerk reaction to 3) might be that they all need to shape up, but
experience seems to relegate that reaction to the pile of wishful
thoughts that lead nowhere.

IIRC, Greg K-H once tried to extend an offer to HW vendors to the effect
of helping with opening their code base, with the reward of helping
write drivers. I don't know what came of it, but I imagine that I would
have heard, if it was a roaring success.

As a user first, and only secondly a developer, I'd like my HW to work,
and finding fully supported gear can still be hard if not impossible,
but I imagine that if we had a central place to list deprecations (and,
possibly, "victims" of them), a lot of grief could be avoided by simply
pointing vendors to that central resource and saying "here is what you
need to know for your driver to keep working - now get to it".

As said, I'm more of a user, so I may be unaware of practices already in
place to mark commits as causing deprecation, but if such practices
exist, I should be able to whip up some sort of script that periodically
does a "git log" and collates deprecations into some format that could
then be parsed by a bash script grepping various out-of-tree code bases
and notifies the relevant parties.

I'd be willing to have a go at such functionality as well as hosting the
info (at least until some vendor realizes the value and donates to it),
but I'd hate to go off into too many wrong directions, if those can be
avoided by feedback here.

Best regards,

Sune Mølgaard

Re: [RFC] Summarizing deprecations

[Greg KH]

On Sat, May 31, 2014 at 04:04:05AM +0200, Sune Mølgaard wrote:
> Dear list,
> 
> In order to keep this non-code RFC brief, allow me to list a few
> observations and then a proposal, that I shall be happy to engage in,
> but for which I'd like a bit of guidance:
> 
> 1) System calls get superseded and deprecated on a regular basis
> 2) Keeping track of deprecations can be difficult
> 3) HW vendors with out-of-tree drivers allocate too few resources to
> handle 1) and 2)
> 4) Out-of-tree drivers usually fail to take deprecations into
> consideration, and then breaking when deprecation leads to removal
> 
> A knee-jerk reaction to 3) might be that they all need to shape up, but
> experience seems to relegate that reaction to the pile of wishful
> thoughts that lead nowhere.

Not true at all.

> IIRC, Greg K-H once tried to extend an offer to HW vendors to the effect
> of helping with opening their code base, with the reward of helping
> write drivers. I don't know what came of it, but I imagine that I would
> have heard, if it was a roaring success.

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.

> As said, I'm more of a user, so I may be unaware of practices already in
> place to mark commits as causing deprecation, but if such practices
> exist, I should be able to whip up some sort of script that periodically
> does a "git log" and collates deprecations into some format that could
> then be parsed by a bash script grepping various out-of-tree code bases
> and notifies the relevant parties.

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

thanks,

greg k-h

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

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

Re: [RFC] Summarizing deprecations

[Sune Mølgaard]

Hi again, and thank you still for interacting,

Greg KH wrote:
> 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.

For at least one of the manufacturers, I have already pointed them in
your direction with regards to the previously mentioned project. They
lamented that they would love to take you up on your offer, but that
their legal department was less than enthusiastic, based on fear of
repercussions from their chip suppliers.

This particular company could be a candidate for positive nudging from
stronger entities than myself, as just one guy.

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

I do not propose to adopt backwards compatibility, but see below (as
well as my initial proposal, with a thought to my subsequent
clarifications).

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

I wish it was so simple. My experience has been that they are, as you
say, on their own, but in a much more poignant sense that you suggested.

First of all, many *consumer* hardware vendors will be more than happy
to be "on their own" wrt to Linux and keep their focus on Windows. This
is their choice to make, but in certain circumstances, we do happen to
have a need for interaction (OpenCL support in graphics drivers, for
instance).

What I seem to have ascertained is, that those, major, players in the
field will, usually, assign a very low number of people to the task of
maintaining compatibility with newer kernels, with no corporate support
at all.

This, obviously, provides the raison d'etre for the reverse-engineered
open-source drivers, but as we stand in the here and now, those have a
lot of work to do to come up to speed.

We agree completely, that the way to go is for the vendors to engage
with the OSS driver hackers, but in the interim, some of us will still
need their closed drivers, and this is where my initial RFC came from:

Compilation of the closed drivers, as well as (as seen in a recent
nVidia case) functionality, will be impacted by system call changes.

You are fully correct that we shouldn't keep old and deprecated
functionality around for the sake of those who choose to distribute
closed drivers.

It stands to reason, though, that there may not only be legal obstacles
to supporting OSS drivers, but also that corporate resources allocated
to keeping their "monstrosity" current may be severely lacking.

As a pragmatic *interim* solution, I therefore stand by my initial
proposal - both as a sign of being reasonably, but also for that level
of reasonableness to be a fulcrum for expecting signs (and results) of
good will to come from them as well.

As it stands, I have authored a number of patches that I have posted to
the nVidia forums - most based on deeper analysis by people in the same
forums, but I happen to think that if my proposal gained traction,
nVidia could actually do that work themselves - facilitating ease of use
for those of us who rely on their drivers while we wait for the dawn of
the revolution...

At any rate, it should preclude a marketing drone from referring to an
unnamed engineer classifying a problem as a bug in the kernel, which is
obviously, in reality, caused by a failure to use a new form of ACPI call.

> 
> And buy better hardware next time :)

Sure - do you think a Kickstarter campaign to entice Danish resellers to
stock better hardware (and advertise it as having OSS Linux drivers)
against profit margins, possibly with a secondary goal of sending such
hardware my way, could get any traction, or did you just, unbecomingly,
get elitist on me?

Sincerely,

Sune Mølgaard

Re: [RFC] Summarizing deprecations

[Greg KH]

On Tue, Jun 03, 2014 at 01:12:20AM +0200, Sune Mølgaard wrote:
> Hi again, and thank you still for interacting,
> 
> Greg KH wrote:
> > 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.
> 
> For at least one of the manufacturers, I have already pointed them in
> your direction with regards to the previously mentioned project. They
> lamented that they would love to take you up on your offer, but that
> their legal department was less than enthusiastic, based on fear of
> repercussions from their chip suppliers.
> 
> This particular company could be a candidate for positive nudging from
> stronger entities than myself, as just one guy.

Feel free to follow up with me about this company and contacts
privately, if you feel I can help out there.

> It stands to reason, though, that there may not only be legal obstacles
> to supporting OSS drivers, but also that corporate resources allocated
> to keeping their "monstrosity" current may be severely lacking.

Take away the legal issues (their side, not ours), and then merge the
driver into the kernel and then all of those maintenance issues go
away for the most part, allowing a single developer to just baby-sit the
driver to ensure nothing goes wrong on newer kernel releases.

That's the Linux kernel development model, it's worked really well for
the past 20+ years, creating something that works on more hardware than
any other operating system ever has, so we must be doing something right
here with the model :)

greg k-h

Re: [RFC] Summarizing deprecations

[Steven Rostedt]

On Sat, May 31, 2014 at 04:04:05AM +0200, Sune Mølgaard wrote:
> 
> As a user first, and only secondly a developer, I'd like my HW to work,
> and finding fully supported gear can still be hard if not impossible,
> but I imagine that if we had a central place to list deprecations (and,
> possibly, "victims" of them), a lot of grief could be avoided by simply
> pointing vendors to that central resource and saying "here is what you
> need to know for your driver to keep working - now get to it".

We had that. It was in the Documentation directory called "feature-removal.txt".
But that was always out of date and caused lots of unnecessary conflicts
by the few that added stuff to it that it became more of a pain to have than
it was worth. And commit 9c0ece069b32e8e122aea71aa47181c10eb85ba7 nuked it.

-- Steve