[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Possibly offtopic : Binary only driver

On Sun, 2004-11-21 at 07:40, Mike Hearn wrote:
> On Sun, 21 Nov 2004 16:29:12 +0100, Arjan van de Ven wrote: 
> Sometimes the choice is like this.
> I bought a 3D game. I want to play it.
> a) Go back to Windows
> b) Use a binary driver on Linux
Well I haven't used windows for years and don't plan on starting up
again. I also will not allow a binary-only module in my kernel.
I also won't run any binary-only blob as root, so I'm kind of stubborn
like that.
I guess I won't buy any games that need that kind of closed-source
binary driver. If everyone switched to Linux and had that kind of
attitude then I'm sure vendors would find some way to open up some code.
> > But look at it with a slightly longer purview; about half the bugs
> > reported against the kernel are in the drivers. The fact that the driver
> > sources are available gives us a shot at fixing those, just as the
> > availability of the core source allows us to fix bugs there.

> Well this is just a generalization of "all software should be open
> source". I tend to agree with that, it would be great if that were true.
Not really, It just means that many of the kernel developers want to
only support that which they can. Thats why they added the tainted flag.
Binary-only modules don't benefit them and they can't help you with it. 
> But it's not true, and there are no signs of it suddenly becoming true
> anytime soon. 
Ok but why exactly should the kernel developers care to support that.

> > If the drivers weren't part of that, their quality would lag WAY behind.
> > (And to be honest, you do see that in several binary drivers: bad
> > quality. Nvidia seems to be improving somewhat there but they didn't
> > always have that; others are still struggling).
Yep I hear windows have similar problems with third party drivers.
They also have lots of bloat to support old obsolete and redundant
api's. BTW I remember that this debate was done better online through
some blogs.

I'll snip from some of Kroah's stuff:
[[...I really need to write a article/essay about why Linux does not
have driver api stability. ... It's not that we don't know how to create
a binary api with padding structures out, and offering up new functions,
it's the fact that because we have the source to all of our drivers, we
do not have to.

One minor comment though, the fact that we have the source to everything
changes all of the old rules that operating systems had to live by.
Backwards compatibility is no longer necessary, enabling us to move
faster, and be more flexible than ever. As proof of that, look at the
huge range of machines that Linux runs very well on. Everything from
this tiny little gumstick, up to a 512 way ia64 box. And our drivers
work on all of those platforms, with no changes needed.
... Device support - As I mentioned before, and as you mentioned,
Linux's device support is unmatched anywhere else. We support,
out-of-the-box, more devices than any other operating system. We also
support them on every platform that Linux is supported on (somewhere
over 21 unique architectures with lots of minor arches last I looked).
.... Speed - Last I looked, Linux beat the pants off of any other
operating system on the same exact hardware configuration. ... And, I'm
sure the fact that we don't have to keep around old, broken apis, or
have padded structures to keep binary compatibility might have a little
to do with this speed advantage :) ... Flexibility - I touched on this
up above in the device support point, but Linux scales from very tiny to
very huge systems, all based on the exact same kernel code base. ... ]]

So binary-only drivers doesn't help people doesn't help people on PPC or
whatever very much. It also doesn't help people testing out Ingo's
realtime preeempt . If/when that gets merged I'm sure the binary-only
problem will get a little trickier -- up Vs. smp and four levels of
preempt ... You going to make at least eight kernel modules?

> > btw the glibc NSS abi is changing all the time ...  X is about to change
> > their driver interfaces because they suffered too much bitrot.

> I'm pretty sure they could not do this without an unacceptable
> performance loss. Perhaps an nVidia engineer should be asked, they are
> easy to contact.
I wouldn't care. If you're closed-source binary-only you run in
userspace non-root, if at all.

GPG Key fingerprint = EF6F 1486 EC27 B5E7 E6E1  3C01 910F 6BB5 4A7D 9677

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]