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]

Message-ID: <BANLkTim9cBiiK_GsZaspxpPJQDBvAcKCWg@mail.gmail.com>
Date:	Fri, 24 Jun 2011 09:45:59 -0400
From:	Devin Heitmueller <dheitmueller@...nellabs.com>
To:	Mauro Carvalho Chehab <mchehab@...radead.org>
Cc:	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, Jun 24, 2011 at 9:29 AM, Mauro Carvalho Chehab
<mchehab@...radead.org> wrote:
>> MythTV has a bunch of these too (mainly so the code can adapt to
>> driver bugs that are fixed in later revisions).  Putting Mauro's patch
>> upstream will definitely cause breakage.
>
> It shouldn't, as ivtv driver version is lower than 3.0.0. All the old bug fixes
> aren't needed if version is >= 3.0.0.
>
> Besides that, trusting on a driver revision number to detect that a bug is
> there is not the right thing to do, as version numbers are never increased at
> the stable kernels (nor distro modified kernels take care of increasing revision
> number as patches are backported there).

The versions are increased at the discretion of the driver maintainer,
usually when there is some userland visible change in driver behavior.
 I assure you the application developers don't *want* to rely on such
a mechanism, but there have definitely been cases in the past where
there was no easy way to detect the behavior of the driver from
userland.

It lets application developers work around things like violations of
the V4L2 standard which get fixed in newer revisions of the driver.
It provides them the ability to put a hack in their code that says "if
(version < X) then this driver feature is broken and I shouldn't use
it."

> In other words, relying on it doesn't work fine.

It's the best (and really only solution) we have today.

>> Also, it screws up the ability for users to get fixes through the
>> media_build tree (unless you are increasing the revision constantly
>> with every merge you do).
>
> Why? Developers don't increase version numbers on every applied patch
> (with is great, as it avoids merge conflicts).

The driver maintainer doesn't *have* to increase the version - he does
it when he thinks it's appropriate.  The point is you are taking that
discretion out of *their* hands, and you yourself are unaware of when
it is actually needed.

You need to stop looking at this from a purist standpoint and think of
how application developers actually use the API.  They need tools like
this to allow them to work around driver bugs while having a source
codebase which operates against different kernels (including kernels
that may still have those bugs).

Sure, in a perfect world where drivers don't have bugs and
applications don't have to run against older kernels, what you are
saying is not illogical.  But then again, we don't live in a perfect
world.

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/