Alan Stern wrote:
On Tue, 18 May 2004, David Brownell wrote:
Alan Stern wrote:
I'm all in favor of something like this. Do you have any ideas on how we
should handle the case where the hub itself was disconnected but we don't
yet know that it's gone? We wouldn't want to log a KERN_ALERT message
when that happens.
The only potential problem is where states are represented as
call stack context in khubd ... so long as there's only one
khubd thread noticing disconnects, there's no way it'd notice
and then communicate (to itself) that disconnect. Right?
I don't understand your point here. Imagine this: hub A reports a new
connection on one of its ports. Khubd sees this and goes through
debouncing etc. While this is happening hub A is unplugged. Since
debouncing failed, khubd wants to disable the port. But it can't, since
hub A won't reply to the CLEAR_FEATURE messages. Since khubd has been
preoccupied with all this debouncing stuff it doesn't yet know that hub A
has been unplugged. Even if it's multithreaded it still might not learn
for a large fraction of a second, not until hub A's parent's status
interrupt message arrives. In the meantime, how do we know to avoid
logging a premature KERN_ALERT message?
That's the scenario I mentioned: state represented by
stack context in khubd. In this case, context that knows
it's going to be first debouncing etc.
That "large fraction of a second" falls into the category
of "retries lasting more than 1/4 sec", right? It should.
(Where 1/4 second is the canonical hub poll interval. It
might be necessary to add a bit of slop there, but it
shouldn't be too much more.)
Other than multithreading khubd, or switching it to a pure state
machine model, the first thing that comes to mind is that the
status change interrupt says which ports changed status, and
they all seem to imply "disconnect" for any device connected
on that port. (Except for remote wakeup signaling, which would
preclude talking to a downstream hub.) So that completion handler
could mark everything NOTATTACHED right away, so retries lasting
more than 1/4 sec could notice that's the case ... and avoid the
nasty log messages).
They don't all imply disconnect. C_PORT_RESET and C_PORT_SUSPEND don't,
for example. So that idea doesn't work.
C_PORT_SUSPEND == remote wakeup ... as I pointed out, when a
port is suspended, that precludes all "normal" hub operations
downstream.
C_PORT_RESET happens in two cases. When enumerating, there
is no device connected -- so as I said, no disconnect. In
the usb_reset_device() case, you'd likely need to move to at
least a partial state machine model.
- Dave
Alan Stern
-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
