lkml.org 
[lkml]   [1998]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [Off Topic Conspiracy Theories] RE: UDI and Free(tm) Software
Chris Johnson writes:
> On Tue, 6 Oct 1998, David Parsons wrote:
>
> > Terry L Ridder wrote:
> > >
> > > david parsons wrote:
> > > >
> > > > In article <linux.kernel.Pine.LNX.3.96.981005175402.18A-100000@z.ml.org>,
> > > > Gregory Maxwell <linker@z.ml.org> wrote:
> > > > >On Mon, 5 Oct 1998, Bill Moshier wrote:
> > > > >
> > > > >> I fail to see it doing anything but strengthening the Linux architecture.
> > > > >> If we have UDI support in the kernel, it does not necessarily require
> > > > >> us to develop UDI modules, and it will potentially give Linux the
> > > > >> access to the latest hardware available, assuming that the various
> > > > >> vendors release UDI drivers for their hardware. If the various vendors
> > > > >> find that they have a problem providing the detailed support for their
> > > > >> board, it should encourage them to provide source code, or detailed
> > > > >> information for their hardware. In either case, I believe Linux wins.
> > > > >
> > > > >No Linux loses. Linux is becoming a very popular driver. Soon many vendors
> > > > >will notice a loss in sales if they provide no Linux drivers.
> > > > >
> > > > >UDI give them a way to throw a cheezy half-assed driver our way.
> > > >
> > > > Writing to a published interface does NOT make a driver cheezy.
> > > > Instead it makes it easier to build a good driver, because you're
> > > > not constantly futzing with the driver to account for interface
> > > > drift, and you can instead spend this energy making the driver
> > > > better.
> > >
> > > Just because a UDI driver is written against the UDI specification
> > > does not imply that it is either a "good" or "bad" driver. It only
> > > means that it meets the UDI specification. There is nothing in the UDI
> > > specification that says either explictly or implicitly that a UDI
> > > driver will in fact work.
> >
> >
> > You realize, of course, that you're speaking absolute nonsense. Why
> > in the name of g-d would any commercial hardware vendor deliberately
> > write device drivers that _don't_ work??
>
> Substitute 'works poorly' or 'is unstable' for 'not working' and you
> wind up with the Windows driver model. Sure he's exagerating, but not
> by much. Hardware manufactures deliberately write drivers that are
> poor or unstable or just plain useless, but they do write them. Why?
> Because they have to make the driver. Just because the manufacturer
> makes a driver doesn't mean that it is good.

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/

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.252 / U:0.024 seconds]
©2003-2011 Jasper Spaans. Advertise on this site