Add constructor of IoUring from raw FD #288
Conversation
The user must communicate the parameters utilized with its construction out-of-band but can otherwise use an existing file descriptor. The library will then map the existing ring's queues. This permits using a pre-opened file descriptor such as one shared by a parent process, or one stashed away to be kept open in systemd's file descriptor store. Keeping a ring open can allow its operations to complete despite the writer's process dying unexpectedly. Additionally, another process might register a personality (IORING_REGISTER_PERSONALITY) to be used as means of effective access controls for operations that must avoid confused deputy scenarios. A ring opened by a parent might also have pre-existing trusted restrictions (IORING_REGISTER_RESTRICTIONS) applied to it. Note that this is _not_ an implementation of `IORING_SETUP_ATTACH_WQ` or of a multi-issuer submission queue.
| @@ -81,6 +81,11 @@ impl IoUring<squeue::Entry, cqueue::Entry> { | |||
| pub fn new(entries: u32) -> io::Result<Self> { | |||
| Self::builder().build(entries) | |||
| } | |||
|
|
|||
| /// Create an `IoUring` instance from a pre-opened file descriptor. | |||
| pub unsafe fn from_fd(fd: RawFd, params: Parameters) -> io::Result<Self> { | |||
There was a problem hiding this comment.
if user uses an existing fd, how does he construct Parameters?
There was a problem hiding this comment.
Good point. In my use case testing I've been a little naughty and used the internal representation with a byte transmute (relying on io_uring_params). Definitely not the route I'd want to promote.
Given that the kernel's interface struct written in io_uring_setup is essentially fixed forever, would it make sense to define a public version of the parameter type with Rust mappings of the attributes? Depending on where we want to handle the unsafety of validating / trusting its attributes, the interface here could take such a new struct or Parameters could be publicly convertible from it.
There was a problem hiding this comment.
I don't have a good idea, but I'm willing to add a #[repr(transparent)] to Parameters, and user needs to call unsafe code to convert it.
|
Thank you! |
* Add constructor of IoUring from raw FD The user must communicate the parameters utilized with its construction out-of-band but can otherwise use an existing file descriptor. The library will then map the existing ring's queues. This permits using a pre-opened file descriptor such as one shared by a parent process, or one stashed away to be kept open in systemd's file descriptor store. Keeping a ring open can allow its operations to complete despite the writer's process dying unexpectedly. Additionally, another process might register a personality (IORING_REGISTER_PERSONALITY) to be used as means of effective access controls for operations that must avoid confused deputy scenarios. A ring opened by a parent might also have pre-existing trusted restrictions (IORING_REGISTER_RESTRICTIONS) applied to it. Note that this is _not_ an implementation of `IORING_SETUP_ATTACH_WQ` or of a multi-issuer submission queue. * Make parameters repr-transparent, add safety note
The user must communicate the parameters utilized with its construction out-of-band but can otherwise use an existing file descriptor. The library will then map the existing ring's queues. This permits using a pre-opened file descriptor such as one shared by a parent process, or one stashed away to be kept open in systemd's file descriptor store.
Keeping a ring open can allow its operations to complete despite the writer's process dying unexpectedly. Additionally, another process might register a personality (IORING_REGISTER_PERSONALITY) to be used as means of effective access controls for operations that must avoid confused deputy scenarios. A ring opened by a parent might also have pre-existing trusted restrictions (IORING_REGISTER_RESTRICTIONS) applied to it.
Note that this is not an implementation of
IORING_SETUP_ATTACH_WQor of a multi-issuer submission queue.