> No, it cannot call tsleep.  It's just like an interrupt routine (actually
> it is run (more or less) as a subroutine to the clock interrupt code),
> so it cannot do anything to the current process.
That's what I thought.  Well, the device exploration needs
to talk to the USB hubs, and to do so it will have to use
the USB controller.  The USB controller is interrupt driven
and calling, e.g. usb_get_device_descriptor() entails
calling tsleep() to wait for the controller to deliver the
data.

So using timeouts is not an option (as I thought).

> It sounds as if you don't know the timeout mechanism:
> 
> You call timeout() with three parameters, the routine to call, an argument,
> and the number of clock ticks (normally derived from the variable hz which
> gives the number of clock ticks per second) to wait before calling this routine.
I did know about timeout, I was just unsure if timeout
routines (by some magic :-) could call tsleep() internally.

> Hope it helps.
I'm afraid not.  I guess I'll have to implement polling...

        -- Lennart