On Tuesday 03 August 2004 08:47, Alan Stern wrote: > > > I think I see what you're saying: You don't see preventing one > > task from interfering with another as a goal. So you don't > > draw the distinction between prevention that's necessary, > > and prevention that's stronger than necessary (since that > > patch changed one line vs, say, a couple dozen). > > No, no. Preventing tasks from interfering with another is absolutely > necessary. I'm saying that even if hub_events() called > down(&hdev->serialize) instread of locktree(), we would still have that > prevention.
No we wouldn't. Consider a task suspending a tree; now khubd comes in and wakes something up that's already been carefully suspended. You're allowing interference ... encouraging it. > > Well, the database folk have bad things to say about event sequences > > that can't be serialized ... in fact locktree() is a serialization > > algorithm, designed to let tasks work concurrently without > > sacrificing several handy characteristics. > > That's a strange way of putting it. Doesn't it make more sense to say > that serialization algorithms _prevent_ tasks from working concurrently, > so that even if they are started at the same time they will still function > correctly? Doesn't the very term "serial" imply non-concurrent operation? Given N events with ordering/sequencing constraints, there are quite a lot of "serializations" that put the events in some non-concurrent sequence. Imagine M concurrent processors, each serializing just enough to write "starting event N now" to a log; that's the idea. The problem of a serialization algorithm is to ensure that whatever sequences happen are legal sequences ... so that when there's no sequence with B before A which can possibly be correct, then B never happens before A. So "A, B, C" is OK, as are "A, C, B" and "C, A, B". > > > I meant to say "suspending them", not "locking them", sorry. Given that > > > usbcore must take responsibility for suspending USB devices and can't > > > delegate it to the driver core, what happens when the device tree > > > traversal needed for proper suspension goes outside the USB boundary? > > > > Good question. I think that the PM core should have a routine that's > > responsible for suspending all of a subtree. Instead it only has code > > to do that for the degenerate subtree: the whole darn system! > > You're still missing my point. The PM core _can't_ have such a routine. > Or if it does, the routine won't work for locking USB devices. > > Why not? In order to lock all the devices in a subtree the PM core first > has to acquire the subsystem rwsem; otherwise the subtree could change out > from under it. The subtree _needs_ to be able to change on the fly. And I'll note that subsystem locks aren't a factor in the PM core today. - Dave ------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
