Re: [RFC] Don't use linux/version.h anymore to indicate a per-driverversion - Was: Re: [PATCH 03/37] Remove unneeded version.h includes from include/

From: Devin Heitmueller
Date: Fri Jun 24 2011 - 14:48:15 EST


On Fri, Jun 24, 2011 at 2:34 PM, Stefan Richter
<stefanr@xxxxxxxxxxxxxxxxx> wrote:
> If the "driver version" is in fact an ABI version, then the driver author
> should really increase it only when ABI behavior is changed (and only if
> the behavior change can only be communicated by version number --- e.g.
> addition of an ioctl is not among such reasons).  And the author should
> commit behavior changing implementation and version number change in a
> single changeset.
>
> And anybody who backmerges such an ABI behavior change into another kernel
> branch (stable, longterm, distro...) must backmerge the associated version
> number change too.
>
> Of course sometimes people realize this only after the fact.  Or driver
> authors don't have a clear understanding of ABI versioning to begin with.
> I am saying so because I had to learn it too; I certainly wasn't born
> with an instinct knowledge how to do it properly.
>
> (Disclaimer:  I have no stake in drivers/media/ ABIs.  But I am involved
> in maintaining a userspace ABI elsewhere in drivers/firewire/, and one of
> the userspace libraries that use this ABI.)

Hi Stefan,

To be clear, I don't think anyone is actually proposing that the
driver version number really be used as any form of formal "ABI
versioning" scheme. In almost all cases, it's so the application can
know to *not* do something is the driver is older than X.

Given all the cases I've seen, it doesn't really hurt anything if the
driver contains a fix from newer than X, aside from the fact that the
application won't take advantage of whatever feature/functionality the
fix made work. In other words, I think from a backport standpoint, it
usually doesn't *hurt* anything if a fix is backported without the
version being incremented, aside from applications not knowing that
the feature/fix is present.

Really, this is all about applications being able to jam a hack into
their code that translates to "don't call this ioctl() with some
particular argument if it's driver W less than version X, because the
driver had a bug that is likely to panic the guy's PC". Sure, it's a
crummy solution, but at this point it's the best that we have got.

Devin

--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
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/