On 12/18/23 08:29, Charles Keepax wrote: > On Mon, Dec 18, 2023 at 01:58:47PM +0100, Pierre-Louis Bossart wrote: >>> why not have a single API that does both? First check if it is supported >>> and then allocate buffers and do the transfer.. What are the advantages >>> of using this two step process >> >> Symmetry is the only thing that comes to my mind. Open - close and send >> - wait are natural matches, aren't they? >> >> We do need a wait(), so bundling open() and send() would be odd. >> > > I agree send->wait->close would be odd, But you just bundle close > into wait. So the API becomes just send->wait, which seems pretty > logical. Fair enough, send()/wait() would work indeed. I guess I wanted to keep the callbacks reasonably small (already 200 lines for the open), but we can split the 'send' callback into smaller helpers to keep the code readable. There's no good reason to expose these smaller helpers to codec drivers. >> But you have a point that the open() is not generic in that it also >> prepares the DMA buffers for transmission. Maybe it's more natural to >> follow the traditional open(), hw_params(), hw_free, close() from ALSA. > > I think this just makes it worse, you are now adding even more > calls. The problem I see here is that, open and close (at least to > me) strongly implies that you can do multiple operations between > them and unless I have misunderstood something here you can't. That's right, the open was not compatible with multiple operations. Collapsing open/send and wait/close sounds more logical, thanks for the feedback.
