Quoting Pete Zaitcev <[EMAIL PROTECTED]>: > > From: Wolfgang Mües <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > > Date: Wed, 14 Nov 2001 19:27:24 +0100 > > > > If you have initialization done in probe() then it is automatically > > > wrong, at very least because you are not running in freely blockable > > > thread. > > > > If I *have* to do some initialisation in probe(), what should I do? > > (Sending about 5-10 control messages to the device).
Then you do it, I guess... I meant "wrong" as "conceptually improper" rather than "system crash imminent, please press your self-destruct buttons, and have a nice day!" :-) > I did not see the original message from Dmitry. I disagree, > probe() only happens on the context of the insmod or its > children, or in init, or khubd. It certainly can call schedule(). It can indeed, but khubd is the problem. It was discussed extensively on l-u-d at least 1 year ago. If the probe() takes some signigicant time to do its work all other users of the thread will have to wait; new device connects, disconnects etc. will not be handled in a timely manner. This is not a fatal error, but usability issue, I think. The original CPiA code accessed the camera to find out the revision of the hardware/firmware. You *can* block in probe(), and in fact you most likely will if you are making calls to other code that can sleep. The problem begins when your probe() takes not 10 ms but 10 s, and during this time the hub stops responding [to anyone else]. I had it done this way in early version of the camera driver, and it was very unpleasant. The thread is shared and is a system-wide resource; that's why you should be cautious with its use. Similarly, blocking in context of insmod/init will cause long delays on reboot and makes the system feel "slow". In most cases the device does not really need to be accessed until someone tries to use it. Dmitri -- Predeterminism was doomed from the start.
msg02573/pgp00000.pgp
Description: PGP signature
