Descriptorless files for io_uring

Posted Jul 19, 2021 20:30 UTC (Mon) by josh (subscriber, #17465)
In reply to: Descriptorless files for io_uring by Cyberax
Parent article: Descriptorless files for io_uring

That's very much the use case this is for. Entries in the fixed file table are assigned by userspace choosing which one to use, not by the kernel assigning a free one.

This is similar to how X Window System clients assign resource IDs: when you create an object like a window or pixmap, you assign the ID yourself from a range of valid IDs you were given, and you can then batch creation and usage of an object in the same batch.

If you then want to use the object outside of io_uring, you can always use an io_uring operation to link the fixed-file into a normal file descriptor, and then use it with normal syscalls. And if you want, you can assign a specific file descriptor yourself rather than relying on the kernel's "allocate the lowest unused number".

Descriptorless files for io_uring

Posted Jul 20, 2021 0:46 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (9 responses)

> And if you want, you can assign a specific file descriptor yourself rather than relying on the kernel's "allocate the lowest unused number".

How?!? This would help me a lot. I can't change all the read/write calls to use io_uring, but I can do that with opens.

Descriptorless files for io_uring

Posted Jul 20, 2021 6:03 UTC (Tue) by josh (subscriber, #17465) [Link] (8 responses)

We can add an operation to link a fixed file into the process file descriptor table, given a fixed file index and an fd. Effectively, dup3 with one fixed file as the source and a non-fixed file as the destination.

Descriptorless files for io_uring

Posted Jul 20, 2021 6:44 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (7 responses)

So basically I'll need to pre-open a dummy file, dup() it a ton of times to reserve descriptors and then have some kind of an allocator for them? How would I do close()? Just use the magic io_uring dup() back to the original dummy file descriptor?

I guess it can work, but it seems kinda hacky.

Descriptorless files for io_uring

Posted Jul 20, 2021 7:08 UTC (Tue) by josh (subscriber, #17465) [Link] (6 responses)

Are you a library or a program? If you're a program, you own the descriptor space; just pick a high base and allocate descriptors above that as you see fit.

If you're a library or otherwise have to cooperatively manage the file descriptor space, you have to take more care, but you could still let your caller tell you a range you can use. Or we could add operations to reserve a range of descriptors for future use.

But ultimately, the best way to have a private space of file descriptors you can allocate as you see fit is to use io_uring with your own private ring and allocate from its fixed file table.

Descriptorless files for io_uring

Posted Jul 20, 2021 7:28 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

> Are you a library or a program?
A program mostly.

> If you're a program, you own the descriptor space; just pick a high base and allocate descriptors above that as you see fit.
But how can I do that? Is it something that's still being planned?

I think I might be missing something, but as far as I understand, all syscalls that create file descriptors can't accept number ranges.

Descriptorless files for io_uring

Posted Jul 20, 2021 8:43 UTC (Tue) by NYKevin (subscriber, #129325) [Link] (2 responses)

dup2/3 can both create new file descriptors at specific numeric values (just pass whatever number you want as newfd). Of course, you still have to call them one at a time, and you still have to track which numbers are available on your own, but the functionality does exist. The concern, as josh noted, is that if a library did this, and then a different library tried to pull the same trick, they could easily end up walking all over each other. But a program doesn't really need to worry about that.

Descriptorless files for io_uring

Posted Jul 22, 2021 7:44 UTC (Thu) by taladar (subscriber, #68407) [Link] (1 responses)

Wouldn't that be trivial to solve by just having parameters in the library for base fd and number of fds after that to use?

Descriptorless files for io_uring

Posted Aug 3, 2021 20:33 UTC (Tue) by tobin_baker (guest, #139557) [Link]

It would be, if a library could ensure that its reservation didn't conflict with another library's reservation. There should be a syscall like mmap(PROT_NONE) to just reserve a range of fds, and fail if it conflicts with an existing reservation. Then the system would promise to never open(), dup(), etc. onto any reserved fd.

Descriptorless files for io_uring

Posted Jul 20, 2021 16:54 UTC (Tue) by Wol (subscriber, #4433) [Link] (1 responses)

So does this then look a bit like FORTRAN?

Okay, you'd need a new open command, but first you'd call a routine to set up your io_uring, and then you have your private file descriptor space - iirc 1 was the tty, 2 might have been the tape drive, up to about 4, and then your program simply allocated file descriptors from 5 upwards. Can't remember the syntax but it was something like

OPEN( unit, filename, attributes)

I guess in C you'd end up doing something like "fd = open(unit, filename, attributes)" where "unit" would be your index into the ring, and "fd" would be whatever the linux file descriptor was, that your uring had block pre-allocated.

Cheers,
Wol

Descriptorless files for io_uring

Posted Jul 22, 2021 12:18 UTC (Thu) by ejr (subscriber, #51652) [Link]

Approximately right for Fortran (no longer all caps). Plus the unit can be an embedded data statement.

I've been watching this and similar things wondering how much it differs from old methods.