linux-mips-fnet
[Top] [All Lists]

Re: Device Drivers

To: linux-mips@fnet.fr
Subject: Re: Device Drivers
From: Thomas Riemer <triemer@apt4g.a3nyc.com>
Date: Sun, 20 Dec 1998 13:33:38 -0500 (EST)
In-reply-to: <367D3F15.36510A78@wrkhors.com>
Not really the same - if your "CASE" tool generated code for different 
OSes.  Why is it that you have to rewrite the code for your OS - even
if you are on the same hardware - and someone else has a working driver
on another OS?   (This is precisely the situation I'm in.  An sii 
driver was written for freebsd.  Unfortunately, the data structures 
are widely different. )  

Device drivers seems like a much smaller domain than what most CASE
tools try to deal with.  

I'm aware of the massive variance between devices - but if you 
take a look at the drivers/scsi directory - the similarity between
the various drivers is frightening - and clearly the amount of duplication
code for statistics, for managing aborts, managing queuing, etc. 
seems to cry out for some sort of abstraction.  That costs time
and effort, sweat and pain.

-Tom

-----------------------------------------------------------------------
Given enough eyeballs all bugs seem shallow.

On Sun, 20 Dec 1998, Steven Lembark wrote:

> T
> > > The same problem as with much other good ideas: Seems to be a good idea, 
> > > but
> > > someone has to do it. And I'm quite sure that a hand-written driver will
> > > offer much better performance if the programmer writing it knows what he's
> > > doing.
> > 
> > This is sort of the same argument that was is about compilers versus
> > writing in straight assembly language.  The compilers seems to have won
> > out.
> 
> almost.  in some situations (e.g., interplanetary space
> craft) you're still stuck with assy language.  there's also 
> the problem of how to write the CASE tool.  compilers didn't
> win out until they could generate reasonably optimized code,
> vs. code that simply worked.  CPU speed also had a lot to do
> with it: as the CPU speeds moved above Dhz the level of 
> optimization required to get a job done decreased.  a 500MHz
> machine can easily spend 50% of its time spinning on devices.
> q.e.d., wasting a few cycles on "non-optimal" code won't hurt.
> 
> looking at the state of today's CASE tools they don't come 
> close to generating the code a skilled programmer can if 
> both work in the same language -- assy, C, whatever.  when
> the CASE tool can generate code nearly equal to a programmers 
> people will begin to switch.
> 
> another problem in using CASE for device drivers is that each
> device -- a specific model of a specific piece of hardware from
> a particular vendor at a particular time -- has its own foibles.
> i've seen different specimens of the "same" hardware from different
> manufacturing plants behave differently at the same rev level,
> let alone different rev levels of the "same" part.
> 
> the SCSI "standard" is supposedly uniform but vendors have
> implemented their own quirks.  result is that you can usually start
> with someone else device driver but will probably have to tailor
> it to the  specific machinery.  the CASE tool for generic
> interfaces would have to be updated for the quirks in each device
> that every vendor comes up with, which pretty much amounts to just
> writing the  drivers.
> 
> -- 
>  Steven Lembark                                   2930 W. Palmer St.
>  Workhorse Computing                             Chicago, IL  60647
>  lembark@wrkhors.com                                   800-762-1582
> ---------------------------------------------------------------------
>   The opinions expressed here are those of this company.
>   I am the company.
> ---------------------------------------------------------------------

<Prev in Thread] Current Thread [Next in Thread>