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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 24 Jun 2011 19:16:30 -0300
From:	Mauro Carvalho Chehab <mchehab@...radead.org>
To:	Andy Walls <awalls@...metrocast.net>
CC:	Devin Heitmueller <dheitmueller@...nellabs.com>,
	Stefan Richter <stefanr@...6.in-berlin.de>,
	Hans Verkuil <hverkuil@...all.nl>,
	Jesper Juhl <jj@...osbits.net>,
	LKML <linux-kernel@...r.kernel.org>, trivial@...nel.org,
	linux-media@...r.kernel.org, ceph-devel@...r.kernel.org,
	Sage Weil <sage@...dream.net>
Subject: Re: [RFC] Don't use linux/version.h anymore to indicate a per-driver
 version - Was: Re: [PATCH 03/37] Remove unneeded version.h includes from
 include/

Em 24-06-2011 18:04, Andy Walls escreveu:
> On Fri, 2011-06-24 at 14:48 -0400, Devin Heitmueller wrote:
>> On Fri, Jun 24, 2011 at 2:34 PM, Stefan Richter
>> <stefanr@...6.in-berlin.de> 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.
> 
> MythTV, for example, used to use the driver version to work around old
> VBI bugs and MPEG encoder quirks that the older version of the driver
> may not have known how to handle:
> 
> https://github.com/MythTV/mythtv/blob/b98d3a98e3187000ae652df5ffebe2beb5221ba7/mythtv/libs/libmythtv/mpegrecorder.cpp#L335
> 
> But for newer versions, MythTV could avoid using its own odd hacks.
> The bleeding edge MythTV now has most of these removed.

Removing it is a good thing.

>> 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".
> 
> Well, not even panics per se, but some thing like the VBI is broken, or
> the volume control doesn't work, IR blaster is works for this version,
> or something else stupid that is very visible to the end user.
> 
> I also use the driver version for troubleshooting problem with users.  I
> roughly know what wasn't working in what version of the cx18 and ivtv
> drivers.  If the end user can tell me the driver version (using v4l2-ctl
> --log-status) along with his symptoms, it makes my life easier.  Being
> able to efficiently help the end user is a win for both me and the end
> user.

If you add it to MODULE_VERSION, you can get the version with:

$ modinfo -F version vivi
0.8.1

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