Possibly offtopic : Binary only driver

Mike Hearn mike at navi.cx
Sun Nov 21 22:34:59 UTC 2004


On Sun, 2004-11-21 at 17:07 -0500, Alan Cox wrote:
> And you don't have a four minute reboot cycle each wrong guess ?

Correct. I'd be surprised if you can't cut that down by using things
like LinuxBIOS. For issues that aren't driver related, VMs?

> I've been there and done it too. Its very different debugging code that you have
> some expectation that a debugger will handle.

Debuggers are often useless working on Wine. Many interesting programs
like iTunes employ anti-debugger code. You typically have to go by
logging frameworks, examining the code, etc. All the old-school
techniques. For race conditions logging can be a problem too, but let's
not go there. Horror stories can wait for some other time :)

Anyway, I don't want to get into an arm-wrestle over who has it worse,
let's just leave it at "it's possible but not easy" :)

> Actually they seem to file bugs with trangaming and friends who in turn
> filter some of them back to relevant places. When "shock rifle in game
> foo hangs DRI" gets back to the DRI folks its suddenely rather useful to
> have DRI source.

Yeah, some users file bugs. That's not related to my original point
which is that the hypothetical "if all users refused to use binary 3D
drivers then vendors would have to open up some source" situation is
silly. It's not going to happen anytime soon, so why discuss it? That
sort of mass boycott *might* occasionally work for very emotive issues
like Nestle baby-milk. It won't happen for something as complicated and
specialist as open source nvidia drivers.

> Except for all the drivers that don't work in XP, or are 98 only. I get so
> much cool stuff off ebay cheap because the (often ex) vendor driver doesnt
> work on 2K/XP.

I'll take a few drivers not working on XP over not being able to buy a
new wireless card that works with Linux. I've tried. The shop refused to
take them back, I'd opened the packaging. The last one even had a
penguin on the website, could probably do the vendors for trading
standards. It's a worthless piece of plastic and metal to me now
(chipset change w/ no model number change).

Yeah I'll definitely take the Windows "occasionally might not work on
XP" situation to the "almost certainly won't work on Linux" situation we
have now, at least for wireless cards. And the situation has got worse
not better. The only supported cards you can get these days seem to be
obsolete.

> An ABI is very very hard to handle. It also works against customers some
> times - eg I long ago found a unix vendor bug that let anyone using rsh 
> control and reconfigure the networking stack. The engineer I knew fixed it
> next day, it took a year to get out properly because it was a kernel ABI issue.

Yeah, that's pretty much worst case example.

> The same criteria apply in Linux land too. I fixed some nasty tty holes. That
> needed an ABI change (and in a couple of cases API change). Would you prefer
> an ABI or security ?

I think most would accept that Linux is more secure than Windows
currently in terms of worms and such, but most people use Windows. One
reason is that Windows supports their hardware and software. So I guess
the logical conclusion is that people do value compatibility more than
security.

This is for desktops, obviously. On servers it's probably the other way
around.

> Vendors do recognize the trade off. RHEL3 has a fixed ABI as best we can
> manage it, but its a hard job.

It's not really fixed. It's just that RHEL revs less often. The next rev
will still be incompatible with the previous.

> The original kernel had about 6K of stack you could use, but at least 2K of
> that had to be free for IRQ handlers. The new kernel has separate stacks
> for IRQ handlers so nothing has changed in available stack except that
> abusers who would previously randomly crash the box now reliably crash it.
> Thats an improvement in itself as unpredictable bugs are bad.

OK. That makes sense. 

Still, I'm no stranger to working around bugs in popular programs - at
the end of the day the purpose of an OS is to run the users programs and
let them use their hardware. It's not to punish the user for buying
stuff from vendors who write buggy software (which 3D card driver has
never had bugs again?). 

thanks -mike

-- 
Mike Hearn <mike at navi.cx>




More information about the devel mailing list