why are ringbuffers bound to an existing file descriptor?

Posted Jun 11, 2024 18:46 UTC (Tue) by donald.buczek (subscriber, #112892)
Parent article: A generic ring buffer for the kernel

I apologize, if these are naive questions.

Why are these ringbuffers implemented as attachments to existing file descriptors of arbitrary types and not as standalone objects which could, for example, be referenced by dedicated file descriptors of a new pseudo-filesystem? That way, epoll and friends could be used for the wait operations. I fail to see why there must be a one-to-one relation between a ringbuffer and an existing file descriptor. Is the only expected application a read/write substitute?

Another question: The original motivation seems to be communication between userspace and kernelspace. But is the implementation now also a proper tool for userspace-only communication between threads? Maybe this second question clarifies the first one: Where would I get my noop-type filedescriptor which only purpose would be to hold a ringbuffer.

why are ringbuffers bound to an existing file descriptor?

Posted Jun 13, 2024 13:42 UTC (Thu) by koverstreet (✭ supporter ✭, #4296) [Link] (2 responses)

Excluding the ringbuffer_wait and ringbuffer_wait syscalls, a ringbuffer is just a region of memory.

So once we switch to futex operations for wait/wake, you'll be able to make your own ringbuffer in shared memory, no kernel involvement.

why are ringbuffers bound to an existing file descriptor?

Posted Jun 14, 2024 17:12 UTC (Fri) by donald.buczek (subscriber, #112892) [Link] (1 responses)

Thanks.

I was just curious whether an unconventional use of the proposed ringbuffer API for userspace to userspace communication would work, assuming that whatever the kernel does with the ringbuffer for the chosen file type doesn't interfere or is taken into account. It's not sensible or needed, though, because that can be done right now and you only need help from the kernel for the non-spinning wait, e.g., via futex, which is available.

Regarding my first question, why a ringbuffer needs to be associated with a file descriptor: Do you expect ringbuffers will only be used as an alternative api to the same data channels as accessible by reading/writing the file descriptors? Is this why there is no standalone ringbuffer? Any kernel feature which supports ringbuffer communication should also support conventional I/O on the same descriptor?

why are ringbuffers bound to an existing file descriptor?

Posted Jun 14, 2024 18:52 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

There are now FDs that don't support regular reading/writing. For example, pidfd().