Thread (7 messages) 7 messages, 4 authors, 2023-07-18

Re: [PATCH 0/2] eventfd: simplify signal helpers

From: Alex Williamson <hidden>
Date: 2023-07-17 22:53:03
Also in: cgroups, dri-devel, intel-gfx, io-uring, kvm, linux-fpga, linux-fsdevel, linux-mm, linux-rdma, linux-s390, linux-usb, linuxppc-dev, lkml, virtualization

Possibly related (same subject, not in this thread)

On Mon, 17 Jul 2023 19:12:16 -0300
Jason Gunthorpe [off-list ref] wrote:
On Mon, Jul 17, 2023 at 01:08:31PM -0600, Alex Williamson wrote:
quoted
What would that mechanism be?  We've been iterating on getting the
serialization and buffering correct, but I don't know of another means
that combines the notification with a value, so we'd likely end up with
an eventfd only for notification and a separate ring buffer for
notification values.  
All FDs do this. You just have to make a FD with custom
file_operations that does what this wants. The uAPI shouldn't be able
to tell if the FD is backing it with an eventfd or otherwise. Have the
kernel return the FD instead of accepting it. Follow the basic design
of eg mlx5vf_save_fops
Sure, userspace could poll on any fd and read a value from it, but at
that point we're essentially duplicating a lot of what eventfd provides
for a minor(?) semantic difference over how the counter value is
interpreted.  Using an actual eventfd allows the ACPI notification to
work as just another interrupt index within the existing vfio IRQ uAPI.
Thanks,

Alex
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help