On Fri, 05 Mar 2010 09:54:06 -0800 (PST) David Miller <da...@davemloft.net> wrote:
> From: Xavier Bestel <xavier.bes...@free.fr> > Date: Fri, 05 Mar 2010 18:50:24 +0100 > > > On Fri, 2010-03-05 at 07:49 -0800, David Miller wrote: > >> From: Daniel Stone <dan...@fooishbar.org> > >> Date: Fri, 5 Mar 2010 17:41:43 +0200 > >> > >> > I understand that you guys are upset about this, so maybe you'd like to > >> > donate, say, 10% of your developer base to help out? That'd be pretty > >> > ace. > >> > >> You have to support less than %10 of the amount of hardware we have to > >> support. > > > > You can't compare a network card and a GPU. The latter is way more > > complex to code for. > > I wasn't talking specifically about network cards. But if you want > specific examples... > > How about the x86 or parisc cpu, and all their derivatives, are those > complex enough for you? :-) > > I've worked on OpenGL capable grapics card drivers of various > vintages, and I honestly don't think there is anything in there more > complex than what we have to deal with in the kernel. I think you must be saying this for the sake of argument. The complexity lies not in the programming interfaces exposed by the device (those indeed are complex, more so than some CPUs, less so than others). The complexity lies in the fact that those interfaces change from revision to revision, and even between boards sharing the same chip. And more than that, the interfaces exposed to applications are spread across many software components, some of which send commands to the hardware directly. The problem Linus ran into is directly related to this fact, because it involved the interfaces between a few of these components. So from that perspective, the graphics stack is the most complex one in Linux by a long shot. It's even worse than if we had STREAMS networking with a ton of different modules up in userspace messing with protocol. :) -- Jesse Barnes, Intel Open Source Technology Center ------------------------------------------------------------------------------ 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel