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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <1308949448.2093.20.camel@morgan.silverblock.net>
Date:	Fri, 24 Jun 2011 17:04:08 -0400
From:	Andy Walls <awalls@...metrocast.net>
To:	Devin Heitmueller <dheitmueller@...nellabs.com>
Cc:	Stefan Richter <stefanr@...6.in-berlin.de>,
	Mauro Carvalho Chehab <mchehab@...radead.org>,
	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/

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.


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

That seems to be the case to me.


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


>   Sure, it's a
> crummy solution, but at this point it's the best that we have got

Yup.  We do have crummier solutions:

Telling the end user to read their kernel source code to figure out what
bugs their driver release has, and to then adjust their application
command line arguments accordingly. ;)


Regards,
Andy

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