[<prev] [next>] [day] [month] [year] [list]
Message-ID: <yDn_z_4GHfSpIzdE7eDKtLqbCz4BJzNUZlJrz1Jy6Mo_4DpsxWOMvOATbxVZWctK7zbAkq_gNk-G6mTZ42QiFRT-4ULUtK-A1LUlUqdu0qo=@protonmail.com>
Date: Tue, 20 Aug 2019 14:47:48 +0000
From: Cosmin Marin <marin.cosmin@...tonmail.com>
To: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: using eventfd between userspace and kernelspace
Hi folks,
I have some doubts regarding the usage of eventfd and I'm seeking for some advice/suggestions. I want to use eventfd in a producer-consumer manner (EFD_SEMAPHORE) between a process's userspace and a kernel module.
The desired behaviour: periodically, a userspace thread writes to the eventfd while some kernel tasks (under the context of other userspace threads) read from it. When the eventfd reaches 0, the readers will block waiting for the producer. The consumers will always terminate at producer's command via an IOCTL.
Now, I have the following doubts:
1) Older versions of Kernel provided a way to read (eventfd_ctx_read) an eventfd from the kernel but that's no longer available; the counterpart for write (eventfd_signal) it's still there, though.
What I am looking for is a portable way between different versions to read an eventfd from kernel. One option is to get a pointer to the "file" structure based on the "fd" and call the corresponding read function (f = fget(fd); f->f_op->read()).
Does anybody see a problem with directly calling f_op->read() ? Obviously, another option would be to reintroduce eventfd_ctx_read.
2) I also need the semantics to be slightly different: I want to be able to reset the eventfd's counter every so often instead of adding to/incrementing the current eventfd value; that is, I need a write() to set the counter to a specific value. In my view some ways for the implementation are either to add a new flag (EFD_COUNTER_SET) that would work together with EFD_SEMAPHORE or a dedicated IOCTL for this purpose.
Any other suggestions/comments ? Would something like that be accepted in upstream ?
Cosmin
Sent with ProtonMail Secure Email.
Powered by blists - more mailing lists