libc: add support for AIO

[atopia]

Add support for the AIO(4) asynchronous IO facility.

[chelmuth]

I replaced the commit for async jobs by my initial proposal commit a6aced7 that keeps the semantic as tight as possible: onl one new API function monitor_async() in Monitor::Pool. This requires a rebase of other topic commits after addressing the upcoming review.

[chelmuth]

I finished the first review - please address my inline comments. Note, I made remarks about coding style issues but only once. Please lookout for further similar errors by yourself.

[chelmuth]

I cleaned up my branches https://github.com/chelmuth/genode/commits/kqueue and https://github.com/chelmuth/genode/commits/aio.

[atopia]

@chelmuth please give my atopia/genode/tree/aio-rebased branch a spin

[chelmuth]

Please see my new aio branch that includes all your changes plus some minor adjustments (libc port-hash update, indentation fixes).

Commit 4ed972c is special as it proposes to change the signatures of async_read and async_write from non-const reference parameters to result type. I suggest to move the seek-position handling into Vfs_plugin::write() as aio has no notion of seek pos, which removes the need for first_run.

I also noticed aio.cc suffers from indentation levels above 4, which could be addressed in a fixup in my opinion.

[atopia]

Unless I have a fundamental misunderstanding about the monitor mechanism, each Job will remain in the Job registry and will be run over and over again until it returns a Function_result::COMPLETE. Therefore it's crucial that bytes_written is also passed into async_write() calls and not only returned one-way as part of Async_result, because on a second call after a partial write, this state will be used to continue where async_write left off when returning false (i.e. incomplete) on the previous job run. Similarly, async_read() needs to learn about complete_read (there might be a better name for that one) in order to skip setting up an offset and queuing a read on a second run, after the first call to complete_read() returned READ_QUEUED.

As for the second idea: Why do you think that AIO does not have a seek pos?
Quoting aio_write(2):

If O_APPEND is not set for the file descriptor, the write operation will occur at the absolute position from the beginning of the file plus iocb->aio_offset.

I read that as meaning that an aio write needs to seek to offset and because the Job is run asynchronously inside the monitor, I found it best to directly include it into the async_write logic and Async_write_state. It is certainly possible to move the initial seek outside of async_(read|write) and let the execute() method in the AIO Function do the initial seeking and record the fact that it has been completed if that is preferred. That does not change either async method's need for having persistent state passed in though.

[atopia]

Now that I quoted it, it seems that I would need to check fd->flags for O_APPEND before honoring the offset parameter. I'll fix that when we have an agreement about where to seek.

[atopia]

Thanks for the little fixes!

[chelmuth]

As for the second idea: Why do you think that AIO does not have a seek pos? Quoting aio_write(2):

If O_APPEND is not set for the file descriptor, the write operation will occur at the absolute position from the beginning of the file plus iocb->aio_offset.

The last sentence of the quoted paragraph from https://pubs.opengroup.org/onlinepubs/9799919799/functions/aio_write.html reads like follows.

After a successful call to enqueue an asynchronous I/O operation, the value of the file offset for the file is unspecified.

Blending this with O_APPEND does not re-enable a seek position, but an append mode. Do you already ensure the order of operations as stated in the spec?

Unfortunately, I entirely missed the fact that the VFS API still depends on the seek position stored in the VFS handle for implementing a pread/pwrite like semantic. Let's discuss offline tomorrow after I had some time to ponder on this.

[atopia]

Yes, I remember that the file offset is unspecified, but honestly I've just relied on the seek mechanism internally (basically thinking that just because it is unspecified after queueing an async op does not mean that I can't use it internally from within the subsystem). However - you are raising a valid point w.r.t. the order of operations. Although my understanding is that the monitor will run the Jobs in the order they were queued, for example async writes could still be interleaved if there is a partial write, then the job returns as incomplete, then the next async job on the same file runs with another partial write etc. I'll also think about what the requirements and guarantees really should be and then we can discuss offline!