On Tue, Jun 04, 2024 at 10:50:26AM +0000, Nitesh Shetty wrote: >>> + if (!cio) >>> + return -ENOMEM; >>> + atomic_set(&cio->refcount, 1); >>> + cio->waiter = current; >>> + cio->endio = endio; >>> + cio->private = private; >> >> For the main use this could be allocated on-stack. Is there any good >> reason to not let callers that really want an async version to implement >> the async behavior themselves using suitable helpers? >> > We cannot do on-stack allocation of cio as we use it in endio handler. > cio will be used to track partial IO completion as well. > Callers requiring async implementation would need to manage all this > bookkeeping themselves, leading to duplication of code. We felt it is > better to do it here onetime. > Do you see it any differently ? We don't really to these async variants for other in-kernel I/O, so unless we have a really good reason I'd not do here. The usual approach is to just have a submission helper for async in-kernel special bios types, and the let the caller handle the rest.
