Re: [PATCH 1/4] fastboot: Asynchronous function calls to speed up kernel boot

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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

[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux