lio_listio(2): add LIO_FOFFSET flag to ignore aiocb aio_offset

[kib]

Summary

and use the current file offset instead.

[asomers]

Will an operation with LIO_FOFFSET update the current file offset? What happens if two or more operations both specify LIO_FOFFSET? lio_listio does not specify the order in which the operations will be evaluated. Given that, this flag can't be used if two or more operations affect the same file. And IMHO lio_listio isn't very useful with such a restriction.

lib/libc/sys/lio_listio.2

25 ↗

(On Diff #132737)

Don't forget to update .Dd

[kib]

In D43448#990314, @asomers wrote:

Will an operation with LIO_FOFFSET update the current file offset?

Yes.

What happens if two or more operations both specify LIO_FOFFSET? lio_listio does not specify the order in which the operations will be evaluated. Given that, this flag can't be used if two or more operations affect the same file. And IMHO lio_listio isn't very useful with such a restriction.

One of them would do the update first, and another one follows. It is up to caller to care.

I used lio_listio(2) to add the flag because it is extensible, unlike aio_read*(), and I do not want to add yet another syscall variant. I do think that typical use would be with nelem = 1.

[asomers]

In D43448#990316, @kib wrote:

In D43448#990314, @asomers wrote:

Will an operation with LIO_FOFFSET update the current file offset?

Yes.

What happens if two or more operations both specify LIO_FOFFSET? lio_listio does not specify the order in which the operations will be evaluated. Given that, this flag can't be used if two or more operations affect the same file. And IMHO lio_listio isn't very useful with such a restriction.

One of them would do the update first, and another one follows. It is up to caller to care.

I used lio_listio(2) to add the flag because it is extensible, unlike aio_read*(), and I do not want to add yet another syscall variant. I do think that typical use would be with nelem = 1.

Why would you use lio_listio with nelem == 1 ?

[kib]

In D43448#990317, @asomers wrote:

In D43448#990316, @kib wrote:

In D43448#990314, @asomers wrote:

Will an operation with LIO_FOFFSET update the current file offset?

Yes.

What happens if two or more operations both specify LIO_FOFFSET? lio_listio does not specify the order in which the operations will be evaluated. Given that, this flag can't be used if two or more operations affect the same file. And IMHO lio_listio isn't very useful with such a restriction.

One of them would do the update first, and another one follows. It is up to caller to care.

I used lio_listio(2) to add the flag because it is extensible, unlike aio_read*(), and I do not want to add yet another syscall variant. I do think that typical use would be with nelem = 1.

Why would you use lio_listio with nelem == 1 ?

Because you can specify op with modifiers. This is impossible with current syscalls like aio_read(2).

[asomers]

In D43448#990336, @kib wrote:

In D43448#990317, @asomers wrote:

In D43448#990316, @kib wrote:

In D43448#990314, @asomers wrote:

Will an operation with LIO_FOFFSET update the current file offset?

Yes.

What happens if two or more operations both specify LIO_FOFFSET? lio_listio does not specify the order in which the operations will be evaluated. Given that, this flag can't be used if two or more operations affect the same file. And IMHO lio_listio isn't very useful with such a restriction.

One of them would do the update first, and another one follows. It is up to caller to care.

I used lio_listio(2) to add the flag because it is extensible, unlike aio_read*(), and I do not want to add yet another syscall variant. I do think that typical use would be with nelem = 1.

Why would you use lio_listio with nelem == 1 ?

Because you can specify op with modifiers. This is impossible with current syscalls like aio_read(2).

What is the intended application, anyway?

[kib]

In D43448#990348, @asomers wrote:

What is the intended application, anyway?

https://lists.freebsd.org/archives/freebsd-threads/2024-January/000256.html

[jhb]

FYI, I think doing this in lio_listio on the kernel side makes sense. You could add userland-only wrappers if desired for aio_read2(), etc. that invoke lio_listio with nelem == 1. It would be more ideal if the current aio_read was actually called aio_pread so that we could better mirror existing naming, but that ship has sailed.

lib/libc/sys/lio_listio.2

81 ↗

(On Diff #132737)

The implementation also handles LIO_READV and LIO_WRITEV so it seems like maybe we should document those as well?

[kib]

Add aio_read2() and aio_write2().

[asomers]

lib/libc/gen/aio_read2.c

36 ↗

(On Diff #133697)

The LIO_FOFFSET should go in aio_lio_opcode, not lio_listio's mode argument. Also, you shouldn't pass aio_sigevent to lio_listio. If you do that, you'll get doubled notifications. Finally, lio_listio may return EIO if an operation fails. If that happens, I think aio_read2 should call aio_error on the operation and return that.

lib/libc/gen/aio_write2.c

36 ↗

(On Diff #133697)

As with aio_read2:

• The LIO_FOFFSET should go in aio_lio_opcode, not lio_listio's mode argument.
• You shouldn't pass aio_sigevent to lio_listio. If you do that, you'll get doubled notifications.
• lio_listio may return EIO if an operation fails. If that happens, I think aio_write2 should call aio_error on the operation and return that.

lib/libc/sys/aio_read.2

63 ↗

(On Diff #133697)

[kib]

Try to properly use lio_listio().

[kib]

Include the updated man page

[jhb]

lib/libc/gen/aio_read2.c

36 ↗

(On Diff #133697)

Ah, I had assumed the aio_*2() variants would take a flag argument, and for now we'd have an AIO_FOFFSET flag or the like that would set LIO_FOFFSET if present.

[kib]

Change aio_read2/write2 to take flags arg.
[Man pages are not updated until we agree on the interface]

[kib]

Upload the right patch.

[kib]

Yet another attempt to generate the right diff.

[vini.ipsmaker_gmail.com]

sys/sys/aio.h

60

You could also add AIO_OP2_VECTORED (LIO_VECTORED).

[kib]

Add AIO_OP2_VECTORED

[jhb]

I was going to say that if we agreed on the interface we might want to have aio_readv2() and aio_writev2(), but I'm happy with instead having the aio_read2 function accept a vectored flag.

lib/libc/sys/aio_write.2

254 ↗

(On Diff #133799)

lib/libc/sys/lio_listio.2

87 ↗

(On Diff #133799)

88 ↗

(On Diff #133799)

[kib]

Update documentation for aio_*2() describing the flags.
Fix man pages issues noted by jhb.

[jhb]

lib/libc/sys/aio_read.2

99 ↗

(On Diff #133811)

Adding this explicit statement might be useful (and in aio_write.2).

101 ↗

(On Diff #133811)

This reads slightly better to me

103 ↗

(On Diff #133811)

186 ↗

(On Diff #133811)

263 ↗

(On Diff #133811)

lib/libc/sys/aio_write.2

115 ↗

(On Diff #133811)

117 ↗

(On Diff #133811)

195 ↗

(On Diff #133811)

265 ↗

(On Diff #133811)

I liked the version you used in aio_read.2 better

lib/libc/sys/lio_listio.2

88 ↗

(On Diff #133811)

[kib]

Man page fixes

[kib]

Rebased after libsys commits.