Re: [RFC] Small PCI core patch

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

> If the choice instead is to embrace current graphics hardware, then
> given the current state of the market, I don't see any other
> alternative than using the proprietary drivers and OpenGL stacks. The
> path in that direction is something like Xgl.  We can wish for a
> non-proprietary choice on the current hardware, but the reality is
> that we are not going to get it.

As long as they don't need to put binary junk in the kernel, they can
keep the binary junk in userland, where it belongs. That is at least
acceptable and legal, even if it's not a great situation.

The problem is they load these multi-megabytes blocs that want to hook
into SMM BIOS interrupts, ACPI, VM, etc... all over the place and do all
sort of junk in your kernel. Say goodbye to any kind of stability and
maintainability of a kernel loaded with that crap.

And pretty much all of the crap in there doesn't have any good reason to
be closed source. That's all just plumbing. A lot of that could even be
shared between video drivers (they could use the DRI interface for
example, and if it's not enough for them, extend it). That is not where
the actual IP is.

But the real reasons are elsewhere anyway. They don't wnat to opensource
because they don't want to open the gazillion security holes in their
stuff (afaik, the binary drivers make absolutely no verification of the
command streams passed from userland, you can make the card do whatever
you want from any user context, including arbitrary DMA to/from system
memory), the various comments & workarounds for HW bugs that aren't
supposed to exist and might make some customers want to throw the cards
back at them, the disgusting pile of smelly windows-originated library
they link in and wrap all over the place to make linux look like NT,
etc...

And we do _not_ want that in the kernel. There is no point in having
linux on the desktop if it's at the cost of it being the same crap that
windows is.

Ben.