linux-kernel - Re: [git pull] drm request 3

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]

Date:	Fri, 5 Mar 2010 09:28:18 +1000
From:	Dave Airlie <airlied@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Stephane Marchesin <stephane.marchesin@...il.com>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Dave Airlie <airlied@...ux.ie>, linux-kernel@...r.kernel.org,
	dri-devel@...ts.sf.net
Subject: Re: [git pull] drm request 3

>>
>> Its nouveau project not X not DRM, stop generalising the situation.
>
> Is it really just nouveau? I've not looked, but I bet the intel driver and
> the radeon driver have _exactly_ the same "oh, I'm the wrong version, I
> will now kill myself" behavior.
>
> I certainly seem to remember some similar issues with the intel driver
> long long ago.
>
> What would happen if I changed DRIVER_PATCHLEVEL to 1 for the i915 driver?
> Would it try to handle it gracefully? Or are we in the same situation that
> the intel driver guys can never fix anything fundamental without doing a
> whole flag day?

Patchlevel never changed in intel, but if you changed the MINOR back to 1 then
shit would break, exactly like any userspace shared library.

It'll fall over in userspace, because userspace has minimum versioning
requirements
same as if you change all the udev interfaces back 6 years nothing
boots anymore,
or you remove the wireless interfaces or xattrs from ext3. I thin

The standard DRM versioning interface is

MAJOR - don't change this ever except for second coming. Radeon KMS
is the only driver to have bumped this interface version, and we still
support the 1.0.0
if you turn off modesetting. Mach64 bumped it once but we never
upstreamed either
version.

MINOR - optionally bump this when you add a new API, new feature, new chipset,
now we generally just add a new GETPARAM, which the userspace can check for and
do the correct thing.

PATCHLEVEL - ideally bump this for small non-user visible changes, in practice
nobody touches this ever. Nouveau have "abused" this to provide pre
1.0.0 version
number, when they release version 1.0.0 they are expected to follow standard drm
versioning rules.

Now just like in userspace, if you add features to the minor number,
userspace driver
will come to depend on these features being there. If you dropped the
intel minor
to 1.1 it would crap itself all over the place, same as if you
starting trying to ship glibc2.0
on a glibc2.1 distro. We have never worried about new userspaces
running on really
old kernels, because generally 3-4 years has been good enough for distros.

This is a nouveau problem not a drm problem.

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