Whoa!! You're painting with a pretty broad brush here.
Most hardware vendors are probably not out to sabotage their own
products by "deliberately" writing bad drivers. There are probably:
(a) some cases of drivers written by people who aren't
qualified/knowledgeable,
(b) some cases of drivers written by people who are driver geniuses,
(c) lots of cases of drivers written by people who don't have as much
time as they'd like because they have to hurry up and finish the
driver for OS A so that they can write the driver for OS B, C, D,
E, F, and G.
(d) rare exceptions of hardware manufacturers intentionally
instructing their developers to write poor drivers.
As a driver writer for a hardware manufacturer I take exception to
your representation of my efforts. While drivers I produce may have
some bugs every so often, that's usually because of (c) (hopefully not
a :) but never (d).
Yes, sometimes hardware manufacturers do deliver drivers that have
problems or don't meet the marketed feature list (yet? ever?).
However, this is more likely due to lack of appropriate Software
Process Modelling and Control in the face of marketing time pressures
rather than blatant rejection of their customers.
>
> The main trust of an argument against UDI is that the stability of any
> operating system is only as good as the drivers. How many times has
> Windows crashed on you? How many of those crashes were because of
> driver problems? I have wWindows crash all the time but I don't know
> if it's a driver problem or not... there's just no way to tell.
>
> The point he is trying to make (and I'm not saying that I agree or
> disagree) is that if Linux starts using UDI drivers we lose
> stability.
Not necessarily. Because of the way UDI is structured, it provides
the OS much better control over determining where the driver lives,
what driver is currently active, and what the driver is allowed to
do. UDI will allow much better diagnosis of driver problems and
tracking of the culprit and can even "kill" or "pearl" a driver to
stop it from functioning without the machine crashing.
For those more interested in the point, the above advantages come from
having explicit regions and region interfaces within UDI and I'd be
glad to explain further (here or individually).
Will this catch everything that kernel-mode code can do? No.
Will this stop people (any people) from writing bad drivers? No.
Does it make it easier to know how to write a driver? Yes.
Does it make it easier to apply validation/certification? Yes.
Does it separate the driver from the OS to allow the OS to
apply explicit managment to the driver if written that way? Yes.
One perspective that hasn't been discussed is that UDI may *force* hardware
vendors to write better drivers... if they don't someone else will (at
the same time, it makes it *easier* for hardware vendors to write
better drivers). Isn't that already how the game is played already
except that with UDI its more of a "winner take all" situation? Since
winning is likely to be based on stability, performance, and features,
there's every reason for a Linux developer to expect that they can
"win".
This is really a glass half-full or half-empty issue in spades.
Regards,
Kevin
>
> Let's discuss that please.
>
> Chris
>
-- ________________________________________________________________________ Kevin Quick Interphase Corporation Engineering Dallas, Texas kquick@iphase.com http://www.iphase.com 214.654.5173- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/