Re: Possibly offtopic : Binary only driver

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

 



On Sun, 21 Nov 2004 17:04:35 +0100, Arjan van de Ven wrote:
> c) Buy only supported 3D cards, or cards with it's proprietary component
> in userspace

I'm not aware of any (good) 3D cards with open source drivers. Saying do
it in userspace is just saying that somebody else has to deal with
binary-only code. Nobody *likes* dealing with that, but it's something
that has to be done anyway.

> 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. 

Yes I understand that. Bugs in drivers are *always* a big deal though.
>From a desktop users POV a bug in the kernel or a bug in the X server
drivers are basically equivalent, both kill the session dead.
Userspace/kernelspace doesn't matter in that instance.

I think you imagine everybody will blame the kernel developers for driver
bugs. If communication is good enough there's no reason why that should be
so.

> 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).

OK.

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

Here is the first line of my original email:

> Stability is about managing change, not preventing it.

I don't know whether udev was a 2.6 thing that was just not used in FC2,
but all I know is that I upgraded my system and now stuff doesn't work. If
udev was known to be a breaking change, why was it not integrated at the
*start* of the 2.6 series so vendors could say

"OK our current driver only works with 2.4 series kernels. You'll have to
wait a bit for a 2.6 compatible driver"

as opposed to now where it seems nearly every Fedora upgrade breaks
something new.

Nobody says stability prevents progress. That just isn't so. It may mean
saving up lots of changes to integrate at once in one big release rather
than constantly introducing them over time. I don't think people would
mind so much if a driver written for 2.4 worked for the lifetime of the
2.4 series, and a different driver was needed for 2.6.

Here's a post from a Linux sysadmin who ended up going with Solaris for
some new systems because of this issue. He explains it better than me:

http://linux.slashdot.org/comments.pl?sid=130413&cid=10880742

Relevant quote:

"In fact, I recently had to ditch Linux for a project which required four
different third-party add-ons, because I couldn't find a Linux
distribution common to those supported by all four. We had to buy a Sun
machine and use Solaris, because Sun has the common sense to keep a
consistent driver API across each major version."

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

Well, there you go. The 3D market is cut-throat, an avoidable performance
loss was probably deemed too high a cost.

thanks -mike


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux