From: Andy Lutomirski <luto@amacapital.net>
To: Steven Whitehouse <swhiteho@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
David Howells <dhowells@redhat.com>,
Ray Strode <rstrode@redhat.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Nicolas Dichtel <nicolas.dichtel@6wind.com>,
raven@themaw.net, keyrings@vger.kernel.org,
linux-usb@vger.kernel.org,
linux-block <linux-block@vger.kernel.org>,
Christian Brauner <christian@brauner.io>,
LSM List <linux-security-module@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Linux API <linux-api@vger.kernel.org>,
Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
Al Viro <viro@zeniv.linux.org.uk>,
"Ray, Debarshi" <debarshi.ray@gmail.com>,
Robbie Harwood <rharwood@redhat.com>
Subject: Re: Why add the general notification queue and its sources
Date: Fri, 6 Sep 2019 10:14:17 -0700 [thread overview]
Message-ID: <930B6F39-4174-46C2-B556-E98ED72E27F8@amacapital.net> (raw)
In-Reply-To: <8e60555e-9247-e03f-e8b4-1d31f70f1221@redhat.com>
> On Sep 6, 2019, at 9:12 AM, Steven Whitehouse <swhiteho@redhat.com> wrote:
>
> Hi,
>
>> On 06/09/2019 16:53, Linus Torvalds wrote:
>> On Fri, Sep 6, 2019 at 8:35 AM Linus Torvalds
>> <torvalds@linux-foundation.org> wrote:
>>> This is why I like pipes. You can use them today. They are simple, and
>>> extensible, and you don't need to come up with a new subsystem and
>>> some untested ad-hoc thing that nobody has actually used.
>> The only _real_ complexity is to make sure that events are reliably parseable.
>>
>> That's where you really want to use the Linux-only "packet pipe"
>> thing, becasue otherwise you have to have size markers or other things
>> to delineate events. But if you do that, then it really becomes
>> trivial.
>>
>> And I checked, we made it available to user space, even if the
>> original reason for that code was kernel-only autofs use: you just
>> need to make the pipe be O_DIRECT.
>>
>> This overly stupid program shows off the feature:
>>
>> #define _GNU_SOURCE
>> #include <fcntl.h>
>> #include <unistd.h>
>>
>> int main(int argc, char **argv)
>> {
>> int fd[2];
>> char buf[10];
>>
>> pipe2(fd, O_DIRECT | O_NONBLOCK);
>> write(fd[1], "hello", 5);
>> write(fd[1], "hi", 2);
>> read(fd[0], buf, sizeof(buf));
>> read(fd[0], buf, sizeof(buf));
>> return 0;
>> }
>>
>> and it you strace it (because I was too lazy to add error handling or
>> printing of results), you'll see
>>
>> write(4, "hello", 5) = 5
>> write(4, "hi", 2) = 2
>> read(3, "hello", 10) = 5
>> read(3, "hi", 10) = 2
>>
>> note how you got packets of data on the reader side, instead of
>> getting the traditional "just buffer it as a stream".
>>
>> So now you can even have multiple readers of the same event pipe, and
>> packetization is obvious and trivial. Of course, I'm not sure why
>> you'd want to have multiple readers, and you'd lose _ordering_, but if
>> all events are independent, this _might_ be a useful thing in a
>> threaded environment. Maybe.
>>
>> (Side note: a zero-sized write will not cause a zero-sized packet. It
>> will just be dropped).
>>
>> Linus
>
> The events are generally not independent - we would need ordering either implicit in the protocol or explicit in the messages. We also need to know in case messages are dropped too - doesn't need to be anything fancy, just some idea that since we last did a read, there are messages that got lost, most likely due to buffer overrun.
This could be a bit fancier: if the pipe recorded the bitwise or of the first few bytes of dropped message, then the messages could set a bit in the header indicating the type, and readers could then learn which *types* of messages were dropped.
Or they could just use multiple pipes.
If this whole mechanism catches on, I wonder if implementing recvmmsg() on pipes would be worthwhile.
next prev parent reply other threads:[~2019-09-06 17:14 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-04 22:15 [PATCH 00/11] Keyrings, Block and USB notifications [ver #8] David Howells
2019-09-04 22:15 ` [PATCH 01/11] uapi: General notification ring definitions " David Howells
2019-09-04 22:16 ` [PATCH 02/11] security: Add hooks to rule on setting a watch " David Howells
2019-09-04 22:16 ` [PATCH 03/11] security: Add a hook for the point of notification insertion " David Howells
2019-09-04 22:16 ` [PATCH 04/11] General notification queue with user mmap()'able ring buffer " David Howells
2019-09-04 22:16 ` [PATCH 05/11] keys: Add a notification facility " David Howells
2019-09-04 22:16 ` [PATCH 06/11] Add a general, global device notification watch list " David Howells
2019-09-04 22:16 ` [PATCH 07/11] block: Add block layer notifications " David Howells
2019-09-04 22:16 ` [PATCH 08/11] usb: Add USB subsystem " David Howells
2019-09-04 22:17 ` [PATCH 09/11] Add sample notification program " David Howells
2019-09-04 22:17 ` [PATCH 10/11] selinux: Implement the watch_key security hook " David Howells
2019-09-04 22:17 ` [PATCH 11/11] smack: Implement the watch_key and post_notification hooks " David Howells
2019-09-04 22:28 ` [PATCH 00/11] Keyrings, Block and USB notifications " Linus Torvalds
2019-09-05 17:01 ` Why add the general notification queue and its sources David Howells
2019-09-05 17:19 ` Linus Torvalds
2019-09-05 18:32 ` Ray Strode
2019-09-05 20:39 ` Linus Torvalds
2019-09-06 19:32 ` Ray Strode
2019-09-06 19:41 ` Ray Strode
2019-09-06 19:53 ` Robbie Harwood
2019-09-05 21:32 ` David Howells
2019-09-05 22:08 ` Linus Torvalds
2019-09-05 23:18 ` David Howells
2019-09-06 0:07 ` Linus Torvalds
2019-09-06 10:09 ` David Howells
2019-09-06 15:35 ` Linus Torvalds
2019-09-06 15:53 ` Linus Torvalds
2019-09-06 16:12 ` Steven Whitehouse
2019-09-06 17:07 ` Linus Torvalds
2019-09-06 17:14 ` Linus Torvalds
2019-09-06 21:19 ` David Howells
2019-09-06 17:14 ` Andy Lutomirski [this message]
2019-09-05 18:37 ` Steven Whitehouse
2019-09-05 18:51 ` Ray Strode
2019-09-05 20:09 ` David Lehman
2019-09-05 18:33 ` Greg Kroah-Hartman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=930B6F39-4174-46C2-B556-E98ED72E27F8@amacapital.net \
--to=luto@amacapital.net \
--cc=christian@brauner.io \
--cc=debarshi.ray@gmail.com \
--cc=dhowells@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=nicolas.dichtel@6wind.com \
--cc=raven@themaw.net \
--cc=rharwood@redhat.com \
--cc=rstrode@redhat.com \
--cc=swhiteho@redhat.com \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).