drm request 3
in [Kernel]
|
Prev: [GIT PULL] SLAB updates for 2.6.34-rc1
Next: [PATCH 1/1] perf: add support for arch-dependent symbolic event names to "perf stat"
From: Matthew Garrett on 4 Mar 2010 15:00 On Thu, Mar 04, 2010 at 11:41:22AM -0800, Linus Torvalds wrote: > Is there some model of versioning inside X _except_ for the "it won't > work" kind of thing? Can we fix this going forward, so that you can have > _real_ versioning (ie multiple installed versions of a libdrm, the way you > can have concurrently multiple installed versions of glibc?) There isn't. I don't think there's any intrinsic difficulty in doing so, other than the buildsystems and X's own unstable driver API. > 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? -- Matthew Garrett | mjg59(a)srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 4 Mar 2010 15:10 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? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Matthew Garrett on 4 Mar 2010 15:50 On Thu, Mar 04, 2010 at 12:07:19PM -0800, Linus Torvalds wrote: > Do you seriously think that that wouldn't make life easier EVEN FOR THOSE > DEVELOPERS that you claim to speak up for? Compared to dealing with Mesa's build system? I honestly wouldn't want to say. But you're right that pushing the job of supporting multiple interfaces out to userspace would be much more tractable here. -- Matthew Garrett | mjg59(a)srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Stephane Marchesin on 4 Mar 2010 16:00 On Thu, Mar 4, 2010 at 12:07, Linus Torvalds <torvalds(a)linux-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(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Maarten Maathuis on 4 Mar 2010 16:30
On Thu, Mar 4, 2010 at 7:18 PM, Linus Torvalds <torvalds(a)linux-foundation.org> wrote: > > > Hmm. What the hell am I supposed to do about > > � � � �(II) NOUVEAU(0): [drm] nouveau interface version: 0.0.16 > � � � �(EE) NOUVEAU(0): [drm] wrong version, expecting 0.0.15 > � � � �(EE) NOUVEAU(0): 879: > > now? > > What happened to the whole backwards compatibility thing? I wasn't even > warned that this breaks existing user space. That makes it impossible to > _test_ new kernels. Upgrading X and the kernel in lock-step is not a valid > model, lots of people are just using some random distribution (F12 in my > case), and you just broke it. > > I see the commit that does this was very aware of it: > > � � � �commit a1606a9596e54da90ad6209071b357a4c1b0fa82 > � � � �Author: Ben Skeggs <bskeggs(a)redhat.com> > � � � �Date: � Fri Feb 12 10:27:35 2010 +1000 > > � � � � � �drm/nouveau: new gem pushbuf interface, bump to 0.0.16 > > � � � � � �This commit breaks the userspace interface, and requires a new libdrm for > � � � � � �nouveau to operate again. > > � � � � � �The multiple GEM_PUSHBUF ioctls that were present in 0.0.15 for > � � � � � �compatibility purposes are now gone, and replaced with the new ioctl which > � � � � � �allows for multiple push buffers to be submitted (necessary for hw index > � � � � � �buffers in the nv50 3d driver) and relocations to be applied on any buffer. > > � � � � � �A number of other ioctls (CARD_INIT, GEM_PIN, GEM_UNPIN) that were needed > � � � � � �for userspace modesetting have also been removed. > > � � � � � �Signed-off-by: Ben Skeggs <bskeggs(a)redhat.com> > � � � � � �Signed-off-by: Francisco Jerez <currojerez(a)riseup.net> > > but why the hell wasn't I made aware of it before-hand? Quite frankly, I > probably wouldn't have pulled it. > > We can't just go around breaking peoples setups. This driver is, like it > or not, used by Fedora-12 (and probably other distros). It may say > "staging", but that doesn't change the fact that it's in production use by > huge distributions. Flag days aren't acceptable. > > � � � � � � � �Linus > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > -- > _______________________________________________ > Dri-devel mailing list > Dri-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel > What i'm about to say is my personal opinion, not that of nouveau as a whole (not even sure if such a thing exists). 1. We are in staging because our abi isn't final yet. 2. We (already) adjusted our way of working to ensure we have a usable and proper codebase by the time we are ready for mainline. 3. Redhat through Ben Skeggs contributes to nouveau (quite a bit i agree). 4. You are forcing red hat to force something on the rest of us. 5. I for one am happy we keep a clean api. 6. We keep an internal kernel tree that is tested to some degree (in this case the abi break was in there for a few weeks iirc) none of the developers asked for a revert. 7. Everyone (users, distros) are (or should) be aware of the nature of this driver, our userspace interface is experimental for that very reason. 8. Experience has tought me that in the case of nouveau, if a developer isn't using a codepath it will bitrot. So please, also take into consideration that this project isn't solely made by red hat and it's usually the other people that get to keep the pieces. Sincerely, Maarten Maathuis. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |