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: Alan Cox on 5 Mar 2010 11:30 On Fri, 05 Mar 2010 08:06:26 -0800 (PST) David Miller <davem(a)davemloft.net> wrote: > From: Daniel Stone <daniel(a)fooishbar.org> > Date: Fri, 5 Mar 2010 18:04:34 +0200 > > > So you're saying that there's no way to develop any reasonable body of > > code for the Linux kernel without committing to keeping your ABI > > absolutely rock-solid stable for eternity, no exceptions, ever? Cool, > > that worked really well for Xlib. > > read() still works the same way it did 30 years ago last time I > checked. Thats disingenous as read() is a method not an interface. It's also wrong because read() and write() behaviour has changed in various ways and old code broke because of it in subtle ways. Keeping the same method behaviour would have required things like new versions of read() for 64bit files, nonblocking, mandlocks, NFS, networking, etc all of which changed the core read() behaviour. I've yet to see anyone meaningfully argue it was the wrong thing to do. Alan -- 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 5 Mar 2010 11:30 On Fri, 5 Mar 2010, Alan Cox wrote: > > Yeah perhaps Fedora should have pushed an update that was smart enough to > handle the Nouveau old/new ABI before the patch went upstream. Hindsight > is an exact science. Alan - it seems you're missing the whole point. 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! Let me quote that second email: "That commit seems to _on_purpose_ try to avoid at all cost being compatible. It not only removes some old entry-points, it literally re-numbers all the ioctl numbers as it does so, apparently entirely in order to just make it difficult to have some libdrm that can handle both versions." So it's not a "before the patch went upstream" issue. The same issue exists _after_ the patch went upstream. 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. Alan, if this had been done in a way that allowed that whole old/new ABI that you mention to work, I wouldn't have been complaining so much! In other words - I've not been complaining about updating the ABI. I've been complaining about doing it in such a way that it's near impossible to go back-and-forth, because the very thing you suggest was made way way harder than it should be. 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: Jesse Barnes on 5 Mar 2010 11:30 On Fri, 5 Mar 2010 08:44:07 +0100 Ingo Molnar <mingo(a)elte.hu> wrote: > It's a bit as if we split up the kernel into 'microkernel' components, did a > VFS ABI, MM ABI, drivers ABI, scheduler ABI, networking ABI and arch ABIs, and > then tried to develop them as separate components. > > If we did then then Linux kernel development would slow down massively while > in reality everyone would _still_ have to have the latest and greatest source > checked out to do some real development work and to be able to implement > features that affect the whole kernel ... > > Linux would become an epic fail of historic proportions if we ever did that. This is a very good point, and something we've been wrestling with in the gfx community. Awhile back we separated the X drivers from the X core; I feel this was a mistake for the reasons you mention above. It's just plain harder to fix issues when you have to rev the ABI with every change, make sure both the old/new and new/old combinations work, and generally improve things like we do inside of Linux. > [*] I realize that it's possibly hard for Xorg to merge with mesa and the > kernel for license reasons, but my technical observation still stands. No we don't need to merge them fortunately. With GEM and KMS we've pushed two major bits of functionality into the kernel; bits that were badly split between all portions of the stack before. With EGL, we can push a lot of what X did into Mesa. There are even some projects to make a very thin X driver or separate display server sit directly on top of Mesa + EGL, unifying things further. So I really think things are getting better here, not worse (the nouveau issue here aside). -- Jesse Barnes, Intel Open Source Technology Center -- 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: Luca Barbieri on 5 Mar 2010 11:30 > I think you need to be clearer about that. Your distribution packaging > may not support that out of the box. There are a variety of ways to do > almsot all of this including having entire parallel X installs for > development work. Sure, but each user must manually find out how to setup that, and create and test the setup himself (or happen to use a distribution that somehow eases that, if any exist). I think that Linus has a good point in saying that this should be provided by default. And ideally not just by the distribution, but upstream, so that people wanting to test bleeding edge DRM drivers (not necessarily just nouveau) can do so more easily, and beable to go back to their working setup by rebooting should something go wrong. > The fundamental problem you can't solve by versioning though is the exact > one here. A new kernel that requires version X of a driver won't help if > the newest version you have is X - 1. Yes, but the fact that you can't have both X - 1 and X at the same time makes it worse, since for instance bisecting won't just work. > Yeah perhaps Fedora should have pushed an update that was smart enough to > handle the Nouveau old/new ABI before the patch went upstream. Hindsight > is an exact science. Well, yes, but it can still be implemented in time for the next distribution releases and the lesson can be learned for similar future situations. -- 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: Alan Cox on 5 Mar 2010 11:40
> 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! What did you expect them to do. They said when you first forced a merge that they would do this. They have no contract that I am aware of to deliver you compatibility, in fact quite the reverse they said they wouldn't be. Then you attribute to malice what was done as a cleanup by people who've pointedly never to commited to a constant API yet "That commit seems to _on_purpose_ try to avoid at all cost being compatible." Great way to make friends. Alan -- 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/ |