lkml.org 
[lkml]   [2005]   [Aug]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/2] external interrupts
On Sun, 21 Aug 2005, Pavel Machek wrote:

> > Here is a set of patches that implements an external interrupt capability
> > in Linux, along with a device driver for a specific hardware device. I
> > submitted the patches several weeks ago, and they drew no comments, which
> > I take to be a good sign. Anyway, I'm
> It was not good sign in this particular case. My reaction was "this is _so_
> overengineered tjat he's probably joking".

Laughter was not wholly unexpected, though I wasn't joking. I'm trying
to be realistic about the lifetime of any given hardware, and IOC4 is
several years old at this point. Couple that with a sincere desire to
preserve application source compatability when (not if) new hardware
appears, and an abstraction layer seemed to be a logical choice. I'm
more than happy to discuss problems in the abstraction layer's interface
and make appropriate changes -- I'm nothing if not obliging.

I do recognize that the code is a bit excessive given that there's
only one known device (IOC4) that is currently supported. However,
the abstraction isn't really all that complicated. The low-level
driver simply provides to the abstraction layer a structure containing
a handful of functions pointers: get/set output modes and timings,
get/set interrupt sources, get timing roundoff information and device
ID. The abstraction layer provides a function to call whenever an
interrupt occurs. Then add in a bit of registration/deregistration
glue so that kernel modules can load and unload. That's pretty much it
-- nothing fancier than needed to decouple hardware implementation details
from the programming interface.

Yes, I suppose I could implement completely seperate hardware drivers
with a consistent interface, and do away with the abstraction layer.
However, that leads to code duplication, which has its own downfalls.
Personally, if I had to pick one poison or the other I'd take
overengineering over maintaining divergent implementations, but the
patch apparently made my predeliction obvious :).

Thanks,
Brent Casavant

--
Brent Casavant If you had nothing to fear,
bcasavan@sgi.com how then could you be brave?
Silicon Graphics, Inc. -- Queen Dama, Source Wars
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-08-22 23:30    [W:0.068 / U:0.408 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site