On Wed, 2009-08-05 at 01:33 +0800, Alan Stern wrote: > On Tue, 4 Aug 2009, Rafael J. Wysocki wrote: > > > Not only that. I'd like to simplify the design, because IMO using one async > > domain would be much more straightforward than using multiple ones. > > > If I understand the async framework correctly, the domains are only used for > > synchronization, ie. if you want to wait for a group of async operations to > > complete, you can put them all into one domain and then call > > async_synchronize_full_domain() to wait for them all together. > > > > You don't need multiple domains to run multiple things in parallel. > > There's a basic confusion going on here. > > Rui is using "async domain" to mean a collection of devices which > will be suspended or resumed serially. Different domains run in > parallel. > > Rafael is using "async domain" to mean a collection of devices which > will be suspended or resumed in parallel. Different domains run > serially. > cool, thanks for stating the confusion so clearly, Alan. :) Hi, Rafael, maybe there is still some confusions about my proposal. I re-read kernel/async.c file, and notice that Arjan calls the domain as *_synchronization_* domain. sorry I use the wrong word before. And I use the synchronization domains just to keep devices dependency. First, the general idea is to suspend/resume those slow devices in parallel. So we don't suspend/resume them synchronously, instead, we move these actions to the global domain. Then, I found that these actions can not be run asynchronously because they depend on other devices. For example, sd depends on SATA controller, we should make sure the PM callbacks of sd and ahci sata controller are run serially. so a synchronization domain is created for them. This is how multiple synchronization domains come from in this proposal. thanks, rui > Once that is cleared up, you should be able to communicate a little > better... :-) > > Alan Stern > -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
