[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200610111256.s47agmgy5gvj3zwz@ws.net.home>
Date: Wed, 10 Jun 2020 13:12:56 +0200
From: Karel Zak <kzak@...hat.com>
To: torvalds@...ux-foundation.org
Cc: David Howells <dhowells@...hat.com>, viro@...iv.linux.org.uk,
dray@...hat.com, mszeredi@...hat.com, swhiteho@...hat.com,
jlayton@...hat.com, raven@...maw.net, andres@...razel.de,
christian.brauner@...ntu.com, jarkko.sakkinen@...ux.intel.com,
keyrings@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] General notification queue and key notifications
Hi Linus,
On Tue, Jun 02, 2020 at 04:55:04PM +0100, David Howells wrote:
> Can you pull this, please? It adds a general notification queue concept
I'm trying to use David's notification stuff in userspace, and I guess
feedback is welcome :-)
The notification stuff looks pretty promising, but I do not understand
why we need to use pipe for this purpose, see typical userspace use-case:
int pipefd[2], fd;
if (pipe2(pipefd, O_NOTIFICATION_PIPE) == -1)
err(EXIT_FAILURE, "pipe2 failed");
fd = pipefd[0];
All the next operations are done with "fd". It's nowhere used as a
pipe, and nothing uses pipefd[1]. The first impression from this code
is "oh, this is strange; why?".
Is it because we need to create a new file descriptor from nothing?
Why O_NOTIFICATION_PIPE is better than introduce a new syscall
notifyfd()?
(We have signalfd(), no O_SIGNAL_PIPE, etc.)
Karel
--
Karel Zak <kzak@...hat.com>
http://karelzak.blogspot.com
Powered by blists - more mailing lists