> > 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.

Hmm, I've got the impression that you wanted to save the demon process.
What process would you block then with the tsleep?

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

timeout is a perfect fit for polling without blocking the complete system.

> I did know about timeout, I was just unsure if timeout
> routines (by some magic :-) could call tsleep() internally.

No, as I said in my previous mail.  Again, what process would you like to
block with the tsleep?

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

Probably.  But polling with timeout will let the machine continue to run
during the poll.

I'm still not sure I understand what you are trying.  Can you give some
more background, please?

Ciao,
Wolfgang
-- 
ws@TooLs.DE     (Wolfgang Solfrank, TooLs GmbH) 	+49-228-985800