Re: [PATCH] fastboot: Introduce an asynchronous function call mechanism

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

> it's very simple. Take the case of doing each sata port probe as an
> asynchronous item. In order to keep a stable device naming/ordering,
> all the sata probes need to be done in sequence

Not really, you need the results to be ordered which simply means you
need a rendezvous and ordered dispatch from that point.

For ATA stability the only serialization points are handling out ataxx:
numbers and handing out device identifiers. You can find all the ports in
parallel and you can probe them all for disks in parallel (Power supply
permitting).

In fact in both those cases you could do it entirely in parallel as you
can order the probe sequence at start time. That in turn means that
you can defer assignation of names, but that might make the boot messages
a bit confusing.

I'd also question call_async as we don't have infinite thread resources
(or anywhere near sufficient) so in fact what you have is
queue_async(arguments)/complete_async_work(result). Also the async call
is exactly that so we need to be very careful people realise that and
don't pass pointers to local stack objects or we will have some truely
hellish debugging to do. In fact I suspect passing a single
'private_data' object as we do for irqs and other async event handlers is
far safer.

Implementing the queue_async_sequenced(arguments) /
complete_async_sequenced() / finalize_sequenced() model would make life a
lot easier for stuff like device probing with ordering as well.

	queue_async_sequenced(sequence, call, finalize, private_data)

queue asynchronous task and if resources exist start it as call(sequence,
private_data)

	complete_async_sequenced - finish this task, store result and if
possible despatch the next one

	finalize_sequenced - wait for all completions in this sequence
then run the finalize method of each strictly in the order that they were
added orginally by queue_async_sequenced.

gives us exactly what is needed for stuff like SATA probe. After the
finalize the ability to restart_async_sequenced() with a new
call/finalize function would be elegant but not essential ...


Alan