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]

Message-ID: <94a0d4531003051259i4478f55djc018da003886872f@mail.gmail.com>
Date:	Fri, 5 Mar 2010 22:59:23 +0200
From:	Felipe Contreras <felipe.contreras@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Luca Barbieri <luca.barbieri@...il.com>,
	Daniel Stone <daniel@...ishbar.org>,
	David Miller <davem@...emloft.net>, skeggsb@...il.com,
	airlied@...ux.ie, linux-kernel@...r.kernel.org,
	jbarnes@...tuousgeek.org, dri-devel@...ts.sf.net, mingo@...e.hu
Subject: Re: [git pull] drm request 3

On Fri, Mar 5, 2010 at 6:19 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> The thing I objected to, in the VERY BEGINNING in this thread, i the fact
> that the thing was done in such a way that it's basically impossible to
> support the old/new ABI at all!

[...]

> The way this was done, it's apparently basically impossible for the Fedora
> people to push out packaged that support both the old and the new kernel.

The reason why the nouveau people wanted to leave the driver in
staging is because they wanted to leave open the option of reshuffling
the API. The Fedora guys integrated this stuff on their own risk, and
linux (because of your pressure), also did. At no point in time
nouveau guys agreed to freeze the API.

Now they have done precisely what was expected; there's no surprise there.

The surprise seems to be that you thought (for some reason), that
reshuffling the API wouldn't break the old (or current in F12)
user-space code. Now, how exactly do you think that could have been
achieved? Even if you have both nouveau_drv-0.0.15.so, and
nouveau_drv-0.0.16.so... What piece of could would choose one rather
than the other? There has never been such a piece of code.

If there was no compatibility code for API re-shuffling, and API
re-shuffling was expected, the resulting breakage was doomed to
happen.

Finally, at least it's possible to compile the radeon driver without
support for DRM, so perhaps nouveau (and other drivers), should check
the kernel drm version at run-time instead, and fall-back to non-drm
mode when the version is not compatible. I think that's a sensible
approach, although that might require a considerable amount of code.
However, that's something to consider for the future, as your current
libdrm/nouveau is not prepared to handle  the DRM API re-shuffle that
_must_ happen.

Cheers.

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