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: Jerome Glisse on 5 Mar 2010 12:40 On Fri, Mar 05, 2010 at 04:31:29PM +0000, Alan Cox wrote: > 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 > Also GPU API is way more complex than any others kernel API (at least to my knowledge) and you can't know if the API you have is the good one until you have a fully working & fast 3D driver ... and that takes either a lot of time with a lot of people. Cheers, Jerome -- 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: Jeff Garzik on 5 Mar 2010 12:50 On 03/05/2010 10:17 AM, Daniel Stone wrote: > On Fri, Mar 05, 2010 at 06:37:18AM -0800, David Miller wrote: >> If it effects such a large number of people, which this noveau thing >> does, it's entirely relevant to everyone. And the way it's breaking >> and making kernel development difficult for so many people matters to >> us. > > Maybe the lesson to be learned from all this is, 'if the developers > don't want something merged because they're not ready and forsee huge > problems in the future, actually listen to them instead of blindly > ramming it in regardless'? But maybe that's just me. That particular horse left the barn when Fedora shipped nouveau in a stable release, not when Linus merged it into his tree. Jeff -- 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: Younes Manton on 5 Mar 2010 13:00 On Fri, Mar 5, 2010 at 11:05 AM, David Miller <davem(a)davemloft.net> wrote: > From: Alan Cox <alan(a)lxorguk.ukuu.org.uk> > Date: Fri, 5 Mar 2010 16:02:17 +0000 > >>> You can't unleash something like this on a userbase of this magnitude >>> and then throw your hands up in the air and say "I'm not willing to >>> support this in a reasonable way." >> >> Not to belabour the obvious - they didn't. Linus ordered them to merge it. > > And I'm arguing not merging it upstream would be like saying > the same thing. > No, it's not like saying the same thing. Not merging it upstream is saying "we're not willing to support this in a reasonable way *at this time*." -- 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: Ingo Molnar on 5 Mar 2010 13:10 * Mike Galbraith <efault(a)gmx.de> wrote: > On the bright side, all this hubbub sends a very positive message to the > noveau development crew. Folks, your work is important. I'd be proud as a > peacock :) Heh, most definitely so! Noveau really is a game-changer i think, it's a big break-through for Xorg IMO. For the first time in Linux history we support 90%+ of graphics hardware in a more or less acceptable way. That is a big deal really and the xorg/drm folks should be proud of that accomplishment. It solves the nvidia.ko mess to a large degree and moves all these things into an actionable technical domain. I'm so much happier to argue with OSS folks who write this code than having to look at nvidia.ko tainted kernel crash logs. Ingo -- 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: Justin P. mattock on 5 Mar 2010 14:20
On 03/05/2010 09:42 AM, Jeff Garzik wrote: > On 03/05/2010 10:17 AM, Daniel Stone wrote: >> On Fri, Mar 05, 2010 at 06:37:18AM -0800, David Miller wrote: >>> If it effects such a large number of people, which this noveau thing >>> does, it's entirely relevant to everyone. And the way it's breaking >>> and making kernel development difficult for so many people matters to >>> us. >> >> Maybe the lesson to be learned from all this is, 'if the developers >> don't want something merged because they're not ready and forsee huge >> problems in the future, actually listen to them instead of blindly >> ramming it in regardless'? But maybe that's just me. > > That particular horse left the barn when Fedora shipped nouveau in a > stable release, not when Linus merged it into his tree. > > Jeff > > > > -- > 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/ > stopped me in my tracks i.g. in order to install using the livecd requires brain surgery. (for me that's fine, but for an average business person/s forget it). Justin P. Mattock -- 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/ |