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: <6a89f9d51003041257j39fde3b6y8bd3336d77f7cf7a@mail.gmail.com>
Date:	Thu, 4 Mar 2010 12:57:19 -0800
From:	Stephane Marchesin <stephane.marchesin@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	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

On Thu, Mar 4, 2010 at 12:07, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
>
> On Thu, 4 Mar 2010, Matthew Garrett wrote:
>>
>> > IOW, we have a real technical problem here. Are you just going to continue
>> > to make excuses about it?
>>
>> I'm not questioning the fact that it would be preferable to provide
>> compatibility. But that compatibility doesn't come for free - someone
>> has to implement it, and when your developer base is almost entirely
>> made up of people who are doing this because they find it fun and
>> interesting rather than because they're paid to, who's going to do it
>> and what functionality is going to be delayed as a result?
>
> The thing is, I violently disagree with your basic premise.
>
> The way things are done now, that developer base actually just makes
> things _harder_ for themselves. They may not be aware that they do so, and
> they may _think_ that it's easier to just ignore versioning, but they are
> wrong.
>
> And I say that from personal experience. Doing incompatible changes in any
> code base makes everything harder. It results in users staying on old
> versions that you _know_ you don't want to support, but because of the
> incompatible change, they can't sanely upgrade.
>
> Seriously.
>
> So I bet we could do that "wrapper nouveau.so" that literally just does
> the "get version, and dlopen the _real_ nouveau-<version>.so".
>
> Quite frankly, I don't know the XAA interfaces (or whatever they are in X
> these days), but somebody who does know them should be able to cook up
> such a wrapper in five minutes (and then spend a day testing it because of
> some silly bug, but whatever..)
>
> Do you seriously think that that wouldn't make life easier EVEN FOR THOSE
> DEVELOPERS that you claim to speak up for?
>

No. It makes our lives much more complicated.

I've worked on the radeon driver before and about half my time was
spent just checking compatibility with multiple kernel/user space
combinations. You have to handle all possible combinations of
DRM+DDX+Mesa drivers, and that gets hairy real quick. Then for nouveau
I decided not to bother until interfaces were stable enough, and I
think all developers agree on that.

I suggest you think about the "do not break user space interfaces"
principle from a graphics developer point of view and what that means
for the user space code. For example, you could take a look at the
radeon DDX or Mesa drivers, which do implement compatibility. In the
long run this leads to little gems like this:
http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/r200/r200_state.c#n2148
Obviously even though there is some form of compatibility, not all
user space/kernel combinations are tested.

In short, the "don't break user space interfaces" principle is making
user space code quality worse for everyone. And it makes our lives as
graphics developers pretty miserable actually

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ