>> could you explain why exactly it needs interrupts disabled for
>> more than 10 ms?
> Anyway, for another example, I've checked the Logitech joystick
> driver. It needs to send an init sequence to the joystick,
> which consists of a series of various delays and writes to the
> joystick port. It needs to be timed precisely, and, so it can't
> allow an interrupts to happen in the middle of the udelay() and
> make it take more time. The whole sequence takes 6+11+7+9 = 33
> ms of cli() time. I could base this on gettimeofday() or PIT
> reading, and forget the cli(), but still an interrupt at the
> wrong time would kill the timing ...
> Just two examples of bad behaving hardware.
Personally, I'd say this problem is more serious than it first
appears, simply because of one thing that appears to have been well
and truly overlooked...
If my memory's right, one of the things that held the transition from
2.0 to 2.2 back was that Linux wanted to get rid of having the kernel
and associated utilities dependant on the precice rate at which the
timer ticks, and thus allow the tick rate to become user-adjustable.
If so, then things like the above will need to be sorted out such that
if a user decides to set his system to use a system clock ticking away
at 10kHz rather than the 100Hz currently used on ix86 based systems,
the kernel will still work without any additional problems...
Best wishes from Riley.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.Amush.cx/pub/rhw/Linux
* http://www.Amush.cx/~rhw/kernel.versions.html
-
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/