> Gerard Roudier wrote:
> >
> > IMHO, this is not an hardware limitation, but a Linux limitation,
> > probably for some performances considerations.
Am I wrong too here?
> > If you hack a SCSI driver regarding request_interrupt flags, you
> > just break some assumption on interrupts state for this drivers.
> > It will be at least required to add some code to disable interrupts
> > at interrupt routine entry point and to restore them on exit from
> > this routine.
>
> No. Linux guarantees that YOUR interrupt will not occur. This means
You are right. But in what was I wrong there?
> that you have free reign about your own device (the ncr8xx). However
> if you cannot tolerate being interrupted for a few microseconds, (e.g.
> if the device has a microsecond timeout after writing a "low word")
> you can opt for running the whole interrupt routine with interrupts
> off to keep things "consistent".
I would want stuff under interrupt to be light but to be able to complete
heavy handling in some software priority that allows interrupts.
On the other hand I donnot like to deal with assumed fast interrupts
routine to be interrupted. For now, the driver uses also a timer handler
that may access controller data too.
Anyway, when the driver accesses some IO registers, I would prefer the
interrupt routine not to be interrupted and masking/unmasking interrupts
has a cost I donnot want to pay.
> I don't think that the NCR is that badly designed, and that running
> with interrupts enabled (all other interrupts) is acceptable.
IMHO, there is a very low ratio of interrupts disabling that is due to
hardware constraints. Most seem to be due to software considerations.
If disabling interrupts if bad design, then there are bunches of bad
designs elsewhere.
Gerard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu