[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 15:40 +0000, Mike Hearn wrote:
> On Sun, 21 Nov 2004 16:29:12 +0100, Arjan van de Ven wrote:
> >> > At least that's the intention. Some people think they can get away with
> >> > not being GPL while still using and depending on deep kernel internals;
> >> > well... to be honest the pain is on them though.
> >> 
> >> Actually the pain is on the users. You just don't see it.
> > 
> > people who choose to use binary modules suffer, I am fully aware of
> > that. I rather not have them suffer that. But in a way they choose that
> > pain when they choose to start using binary modules.
> 
> 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

c) Buy only supported 3D cards, or cards with it's proprietary component
in userspace

> 
> > But look at it with a slightly longer pervue; 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 generalisation of "all software should be open
> source". I tend to agree with that, it would be great if that were true.

well in a way it is, in a way it's not. There is a difference between
userspace software and kernel components here. A "broken" userspace app
at worst breaks itself. A broken kernel component breaks the entire
system, because kernel components have full permission to everything, by
definition. (And before you say "then make it not so", you can't do
that. Not without getting the same issues that makes people not write
userspace drivers today)

> Hm well, can't speak for others but the *only* problems I have with the
> nVidia drivers are when kernel upgrades break them. Last time it was 4k
> stacks,

The 4K stacks issue was a long standing nvidia bug. In older kernels,
there *also* was only 4K stack space, except that when you used more you
could get away with it more (eg as long as you were lucky and didn't get
an interrupt during the time you use too much stack, you didn't crash;
with the new situation you notice this more frequent). 

> this time it's apparently udev.

the udev thing is 1) not caused by the kernel at all and 2) progress.
You don't suggest holding back progress do you ?

> > they do have a choice. they can do things on the other side of the
> > designed stable interface. For example, NVidia could do this. 
> 
> I'm pretty sure they could not do this without an unacceptable
> performance loss.

I didn't want to suggest there were no reasons to chose the kernel side.
It's probably a 5% performance gain or so...

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]