On Sun, 4 Jan 2009, Arjan van de Ven wrote: > + > +typedef u64 async_cookie_t; > +typedef void (async_func_ptr) (void *data, async_cookie_t cookie); > + > +extern void async_schedule(async_func_ptr *ptr, void *data); > +extern void async_synchronize_full(void); > +extern void async_synchronize_cookie(async_cookie_t cookie); Hmm. The cookie use doesn't seem to make much sense. Why do you pass in the cookie to the async function, but don't return it to the caller? That seems backwards - you'd normally expect that it is the _caller_ that wants the cookie (to synchronise with a specific async call), not the callee. But now the only one who knows the cookie is the wrong entry - just the callee, not the caller. Yes, yes, I read the explanation in the comments, and it says that the callee should do it to guarantee its own ordering, and your acpi port thing does that in order to apparently start a sequence that is asynchronous only wrt the synchronous code, but not wrt itself. That's a _very_ odd model, but whatever works. But wouldn't it still make sense to let the caller wait for individual events too? IOW, I'd just suggest changing the interface so that "async_schedule()" also returns the cookie. Linus -- 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
