On Feb 4, 2015 4:16 PM, "David Herrmann" wrote:
>
> Hi
>
> On Thu, Feb 5, 2015 at 12:03 AM, Andy Lutomirski wrote:
> > I see "latencies" of around 20 microseconds with lockdep and context
> > tracking off. For example:
>
> Without metadata nor memfd transmission, I get 2.5us for kdbus, 1.5us
> f
Hi
On Thu, Feb 5, 2015 at 12:03 AM, Andy Lutomirski wrote:
> I see "latencies" of around 20 microseconds with lockdep and context
> tracking off. For example:
Without metadata nor memfd transmission, I get 2.5us for kdbus, 1.5us
for UDS (8k payload). With 8-byte payloads, I get 2.2us and 1.2us.
On Tue, Feb 3, 2015 at 2:09 AM, Daniel Mack wrote:
> Hi Andy,
>
> On 02/02/2015 09:12 PM, Andy Lutomirski wrote:
>> On Feb 2, 2015 1:34 AM, "Daniel Mack" wrote:
>
>>> That's right, but again - if an application wants to gather this kind of
>>> information about tasks it interacts with, it can do
Greg Kroah-Hartman writes:
> On Tue, Feb 03, 2015 at 08:47:51PM -0600, Eric W. Biederman wrote:
>> Andy Lutomirski writes:
>>
>> > On Tue, Feb 3, 2015 at 2:09 AM, Daniel Mack wrote:
>> >> Hi Andy,
>> >>
>> >> On 02/02/2015 09:12 PM, Andy Lutomirski wrote:
>> >>> On Feb 2, 2015 1:34 AM, "Daniel
On Tue, Feb 03, 2015 at 08:47:51PM -0600, Eric W. Biederman wrote:
> Andy Lutomirski writes:
>
> > On Tue, Feb 3, 2015 at 2:09 AM, Daniel Mack wrote:
> >> Hi Andy,
> >>
> >> On 02/02/2015 09:12 PM, Andy Lutomirski wrote:
> >>> On Feb 2, 2015 1:34 AM, "Daniel Mack" wrote:
> >>
> That's righ
Andy Lutomirski writes:
> On Tue, Feb 3, 2015 at 2:09 AM, Daniel Mack wrote:
>> Hi Andy,
>>
>> On 02/02/2015 09:12 PM, Andy Lutomirski wrote:
>>> On Feb 2, 2015 1:34 AM, "Daniel Mack" wrote:
>>
That's right, but again - if an application wants to gather this kind of
information about
On Tue, Feb 3, 2015 at 2:09 AM, Daniel Mack wrote:
> Hi Andy,
>
> On 02/02/2015 09:12 PM, Andy Lutomirski wrote:
>> On Feb 2, 2015 1:34 AM, "Daniel Mack" wrote:
>
>>> That's right, but again - if an application wants to gather this kind of
>>> information about tasks it interacts with, it can do
Hi Andy,
On 02/02/2015 09:12 PM, Andy Lutomirski wrote:
> On Feb 2, 2015 1:34 AM, "Daniel Mack" wrote:
>> That's right, but again - if an application wants to gather this kind of
>> information about tasks it interacts with, it can do so today by looking
>> at /proc or similar sources. Desktop m
On Feb 2, 2015 1:34 AM, "Daniel Mack" wrote:
>
> Hi Andy,
>
> On 01/29/2015 01:09 PM, Andy Lutomirski wrote:
> > On Jan 29, 2015 6:42 AM, "Daniel Mack" wrote:
>
> >> As we explained before, currently, D-Bus peers do collect the same
> >> information already if they need to have them, but they hav
Hi Andy,
On 01/29/2015 01:09 PM, Andy Lutomirski wrote:
> On Jan 29, 2015 6:42 AM, "Daniel Mack" wrote:
>> As we explained before, currently, D-Bus peers do collect the same
>> information already if they need to have them, but they have to do deal
>> with the inherit races in such cases. kdbus
On Jan 29, 2015 6:42 AM, "Daniel Mack" wrote:
>
> On 01/29/2015 12:25 PM, Andy Lutomirski wrote:
> > On Jan 29, 2015 3:53 AM, "Daniel Mack" wrote:
>
> >> Also note that if a receiving peer opts in for a certain piece of
> >> metadata, it should do that that for a good reason, because it needs
> >
On 01/29/2015 12:25 PM, Andy Lutomirski wrote:
> On Jan 29, 2015 3:53 AM, "Daniel Mack" wrote:
>> Also note that if a receiving peer opts in for a certain piece of
>> metadata, it should do that that for a good reason, because it needs
>> that data to process a request. Letting kdbus do the work
On Jan 29, 2015 3:53 AM, "Daniel Mack" wrote:
>
> Hi Andy,
>
> On 01/27/2015 05:03 PM, Andy Lutomirski wrote:
> > On Tue, Jan 27, 2015 at 7:05 AM, David Herrmann
> > wrote:
>
> >> A 16byte copy does not affect the performance of kdbus message
> >> transactions in any way that matters.
>
> > What
Hi Andy,
On 01/27/2015 05:03 PM, Andy Lutomirski wrote:
> On Tue, Jan 27, 2015 at 7:05 AM, David Herrmann wrote:
>> A 16byte copy does not affect the performance of kdbus message
>> transactions in any way that matters.
> What are the performance goals of kdbus? How fast is it ever intended
>
Hello Daniel,
On 01/27/2015 07:14 PM, Daniel Mack wrote:
> Hi Michael,
>
> On 01/27/2015 06:53 PM, Michael Kerrisk (man-pages) wrote:
>> On 01/27/2015 04:23 PM, David Herrmann wrote:
>
>>> I only expect a handful of users to call the ioctls directly. The
>>> libraries that implement the payload-
Hi Michael,
On 01/27/2015 06:53 PM, Michael Kerrisk (man-pages) wrote:
> On 01/27/2015 04:23 PM, David Herrmann wrote:
>> I only expect a handful of users to call the ioctls directly. The
>> libraries that implement the payload-marshaling, in particular. It's a
>> similar situation with netlink.
Hi David,
On 01/27/2015 04:05 PM, David Herrmann wrote:
> Hi
>
> On Mon, Jan 26, 2015 at 3:46 PM, Michael Kerrisk (man-pages)
> wrote:
>> Hello Greg,
>>
>> On 01/23/2015 05:08 PM, Greg Kroah-Hartman wrote:
>>> On Thu, Jan 22, 2015 at 09:49:00AM -0500, Austin S Hemmelgarn wrote:
While I agre
On 01/27/2015 04:23 PM, David Herrmann wrote:
> Hi
>
> On Mon, Jan 26, 2015 at 5:45 PM, Michael Kerrisk (man-pages)
> wrote:
>> On 01/26/2015 04:26 PM, Tom Gundersen wrote:
>>> On Mon, Jan 26, 2015 at 3:42 PM, Michael Kerrisk (man-pages)
>>> wrote:
2. Is the API to be invoked directly by ap
On Tue, Jan 27, 2015 at 7:05 AM, David Herrmann wrote:
> Hi
>
> On Mon, Jan 26, 2015 at 3:46 PM, Michael Kerrisk (man-pages)
> wrote:
>> Hello Greg,
>>
>> On 01/23/2015 05:08 PM, Greg Kroah-Hartman wrote:
>>> On Thu, Jan 22, 2015 at 09:49:00AM -0500, Austin S Hemmelgarn wrote:
While I agree
Hi
On Mon, Jan 26, 2015 at 5:45 PM, Michael Kerrisk (man-pages)
wrote:
> On 01/26/2015 04:26 PM, Tom Gundersen wrote:
>> On Mon, Jan 26, 2015 at 3:42 PM, Michael Kerrisk (man-pages)
>> wrote:
>>> 2. Is the API to be invoked directly by applications or is intended to
>>>be used only behind sp
Hi
On Mon, Jan 26, 2015 at 3:46 PM, Michael Kerrisk (man-pages)
wrote:
> Hello Greg,
>
> On 01/23/2015 05:08 PM, Greg Kroah-Hartman wrote:
>> On Thu, Jan 22, 2015 at 09:49:00AM -0500, Austin S Hemmelgarn wrote:
>>> While I agree that there should be a way for userspace to get the list of
>>> supp
On 01/26/2015 04:26 PM, Tom Gundersen wrote:
> Hi Michael,
>
> On Mon, Jan 26, 2015 at 3:42 PM, Michael Kerrisk (man-pages)
> wrote:
>> 2. Is the API to be invoked directly by applications or is intended to
>>be used only behind specific libraries? You seem to be saying that
>>the latter
On Mon, Jan 26, 2015 at 04:26:53PM +0100, Tom Gundersen wrote:
> The way I read this is that there will (probably) be a handful of
> users, namely the existing dbus libraries: libdus, sd-bus, glib, Qt,
> ell, and maybe a few others. However, third-party developers will not
> know/care about the det
Hi Michael,
On Mon, Jan 26, 2015 at 3:42 PM, Michael Kerrisk (man-pages)
wrote:
> 2. Is the API to be invoked directly by applications or is intended to
>be used only behind specific libraries? You seem to be saying that
>the latter is the case (here, I'm referring to your comment above
>
Hello Greg,
On 01/23/2015 05:08 PM, Greg Kroah-Hartman wrote:
> On Thu, Jan 22, 2015 at 09:49:00AM -0500, Austin S Hemmelgarn wrote:
>> While I agree that there should be a way for userspace to get the list of
>> supported operations, userspace apps will only actually care about that
>> once, when
Hi Greg,
First of all, I seem to have offended you. That was not my intention.
It's certainly not my intent to disparage you or your work (or for
that matter, the other kdbus developers). Insofar as any of the wordings
I've used suggested otherwise, I do apologize.
I'll comment on various point
On Fri, Jan 23, 2015 at 09:19:46PM +0800, Greg Kroah-Hartman wrote:
> On Fri, Jan 23, 2015 at 08:28:20AM +0200, Ahmed S. Darwish wrote:
> > On Fri, Jan 16, 2015 at 11:16:05AM -0800, Greg Kroah-Hartman wrote:
> > > From: Daniel Mack
> > >
> > > kdbus is a system for low-latency, low-overhead, easy
On Thu, Jan 22, 2015 at 09:49:00AM -0500, Austin S Hemmelgarn wrote:
> While I agree that there should be a way for userspace to get the list of
> supported operations, userspace apps will only actually care about that
> once, when they begin talking to kdbus, because (ignoring the live kernel
> pa
On Thu, Jan 22, 2015 at 11:18:50AM +0100, Michael Kerrisk (man-pages) wrote:
> >> And that process seems to be frequent and ongoing even now. (And
> >> it's to your great credit that the API/ABI breaks are clearly and honestly
> >> marked in the kdbus.h changelog.) All of this lightens the burden
On Fri, Jan 23, 2015 at 09:19:46PM +0800, Greg Kroah-Hartman wrote:
> On Fri, Jan 23, 2015 at 08:28:20AM +0200, Ahmed S. Darwish wrote:
> > On Fri, Jan 16, 2015 at 11:16:05AM -0800, Greg Kroah-Hartman wrote:
> > > From: Daniel Mack
> > >
> > > kdbus is a system for low-latency, low-overhead, easy
On Fri, Jan 23, 2015 at 08:28:20AM +0200, Ahmed S. Darwish wrote:
> On Fri, Jan 16, 2015 at 11:16:05AM -0800, Greg Kroah-Hartman wrote:
> > From: Daniel Mack
> >
> > kdbus is a system for low-latency, low-overhead, easy to use
> > interprocess communication (IPC).
> >
> > The interface to all fu
Hi David,
On 01/22/2015 02:46 PM, David Herrmann wrote:
> Hi Michael
>
> On Thu, Jan 22, 2015 at 11:18 AM, Michael Kerrisk (man-pages)
> wrote:
>> On 01/21/2015 05:58 PM, Daniel Mack wrote:
> Also, the context the kdbus commands operate on originate from a
> mountable special-purpose fil
On Fri, Jan 16, 2015 at 11:16:05AM -0800, Greg Kroah-Hartman wrote:
> From: Daniel Mack
>
> kdbus is a system for low-latency, low-overhead, easy to use
> interprocess communication (IPC).
>
> The interface to all functions in this driver is implemented via ioctls
> on files exposed through a fi
On 2015-01-22 08:46, David Herrmann wrote:
Hi Michael
On Thu, Jan 22, 2015 at 11:18 AM, Michael Kerrisk (man-pages)
wrote:
* API oddities such as the 'kernel_flags' fields. Why do I need to
be told what flags the kernel supports on *every* operation?
If we only returned EINVAL on invalid
Hi Michael
On Thu, Jan 22, 2015 at 11:18 AM, Michael Kerrisk (man-pages)
wrote:
> On 01/21/2015 05:58 PM, Daniel Mack wrote:
Also, the context the kdbus commands operate on originate from a
mountable special-purpose file system.
>>>
>>> It's not clear to me how this point implies any pa
Hi Daniel,
On 01/21/2015 05:58 PM, Daniel Mack wrote:
> Hi Michael,
>
> On 01/21/2015 11:32 AM, Michael Kerrisk (man-pages) wrote:
>> On 01/20/2015 07:23 PM, Daniel Mack wrote:
>
>>> It's rather an optional driver than a core kernel feature.
>>
>> Given the various things that I've seen said abo
Hi Michael,
On 01/21/2015 11:32 AM, Michael Kerrisk (man-pages) wrote:
> On 01/20/2015 07:23 PM, Daniel Mack wrote:
>> It's rather an optional driver than a core kernel feature.
>
> Given the various things that I've seen said about kdbus, the
> preceding sentence makes little sense to me:
>
>
On Wed, Jan 21, 2015 at 11:32:59AM +0100, Michael Kerrisk (man-pages) wrote:
> It's rather an optional driver than a core kernel feature.
>
> Given the various things that I've seen said about kdbus, the
> preceding sentence makes little sense to me:
>
> * kdbus will be the framework supporting u
Hello Daniel,
On 01/20/2015 07:23 PM, Daniel Mack wrote:
> On 01/20/2015 02:53 PM, Michael Kerrisk (man-pages) wrote:
>> This is an enormous and complex API. Why is the API ioctl() based,
>> rather than system-call-based? Have we learned nothing from the hydra
>> that the futex() multiplexing sysc
Hi David,
On 01/20/2015 03:31 PM, David Herrmann wrote:
> Hi Michael
>
> On Tue, Jan 20, 2015 at 2:53 PM, Michael Kerrisk (man-pages)
> wrote:
>> On 01/16/2015 08:16 PM, Greg Kroah-Hartman wrote:
>>> From: Daniel Mack
>>>
>>> kdbus is a system for low-latency, low-overhead, easy to use
>>> inte
On 01/21/2015 10:07 AM, Michael Kerrisk (man-pages) wrote:
> On 01/20/2015 02:58 PM, Michael Kerrisk (man-pages) wrote:
>>> +Also, if the connection allowed for file descriptor to be passed
>>> +(KDBUS_HELLO_ACCEPT_FD), and if the message contained any, they will be
>>> +installed into the receivi
Daniel,
On 01/20/2015 02:58 PM, Michael Kerrisk (man-pages) wrote:
> On 01/16/2015 08:16 PM, Greg Kroah-Hartman wrote:
>> From: Daniel Mack
>>
[...]
>> +offset field contains the location of the new message inside the receiver's
>> +pool. The message is stored as struct kdbus_msg at this offset
Hi Michael,
On 01/21/2015 09:57 AM, Michael Kerrisk (man-pages) wrote:
> On 01/20/2015 06:50 PM, Daniel Mack wrote:
>> I've addressed all but the below issues, following your suggestions.
>
> Are your changes already visible somewhere?
Yes, in the upstream repo for the standalone module, which
Hi Daniel,
On 01/20/2015 06:50 PM, Daniel Mack wrote:
> Hi Michael,
>
> Thanks a lot for for intense review of the documentation. Much appreciated.
>
> I've addressed all but the below issues, following your suggestions.
Are your changes already visible somewhere?
> On 01/20/2015 02:58 PM, Mic
Hi David,
On Tue, Jan 20, 2015 at 06:00:28PM +0100, David Herrmann wrote:
[big snip]
> These are just examples off the top of my head, but I think they're
> already pretty convincing.
Thank you for writing this up. This is the information I was
looking for which puts kdbus into context and expla
On 01/20/2015 02:53 PM, Michael Kerrisk (man-pages) wrote:
> This is an enormous and complex API. Why is the API ioctl() based,
> rather than system-call-based? Have we learned nothing from the hydra
> that the futex() multiplexing syscall became? (And kdbus is an order
> of magnitude more complex,
Hi Michael,
Thanks a lot for for intense review of the documentation. Much appreciated.
I've addressed all but the below issues, following your suggestions.
On 01/20/2015 02:58 PM, Michael Kerrisk (man-pages) wrote:
>> +and KDBUS_CMD_ENDPOINT_MAKE (see above).
>> +
>> +Following items a
Hi
On Tue, Jan 20, 2015 at 5:08 PM, Johannes Stezenbach wrote:
> However, let me repeat and rephrase my previous questions:
> Is there a noticable or measurable improvement from using kdbus?
> IOW, is the added complexity of kdbus worth the result?
>
> I have stated my believe that current usage
Hi all,
On Tue, Jan 20, 2015 at 03:53:53PM +0100, Djalal Harouni wrote:
> On Tue, Jan 20, 2015 at 09:42:59AM -0500, Josh Boyer wrote:
> > On Tue, Jan 20, 2015 at 9:31 AM, David Herrmann
> > wrote:
> > >
> > > If you run a 3.18 kernel, you can install kdbus.ko from our repository
> > > and boot a
Hi,
On Tue, Jan 20, 2015 at 09:42:59AM -0500, Josh Boyer wrote:
> On Tue, Jan 20, 2015 at 9:31 AM, David Herrmann wrote:
> > Hi Michael
> >
> > On Tue, Jan 20, 2015 at 2:53 PM, Michael Kerrisk (man-pages)
> > wrote:
> >> On 01/16/2015 08:16 PM, Greg Kroah-Hartman wrote:
> >>> From: Daniel Mack
On Tue, Jan 20, 2015 at 9:31 AM, David Herrmann wrote:
> Hi Michael
>
> On Tue, Jan 20, 2015 at 2:53 PM, Michael Kerrisk (man-pages)
> wrote:
>> On 01/16/2015 08:16 PM, Greg Kroah-Hartman wrote:
>>> From: Daniel Mack
>>>
>>> kdbus is a system for low-latency, low-overhead, easy to use
>>> interp
Hi Michael
On Tue, Jan 20, 2015 at 2:53 PM, Michael Kerrisk (man-pages)
wrote:
> On 01/16/2015 08:16 PM, Greg Kroah-Hartman wrote:
>> From: Daniel Mack
>>
>> kdbus is a system for low-latency, low-overhead, easy to use
>> interprocess communication (IPC).
>>
>> The interface to all functions in
On 01/16/2015 08:16 PM, Greg Kroah-Hartman wrote:
> From: Daniel Mack
>
> kdbus is a system for low-latency, low-overhead, easy to use
> interprocess communication (IPC).
>
> The interface to all functions in this driver is implemented via ioctls
> on files exposed through a filesystem called 'k
On 01/16/2015 08:16 PM, Greg Kroah-Hartman wrote:
> From: Daniel Mack
>
> kdbus is a system for low-latency, low-overhead, easy to use
> interprocess communication (IPC).
>
> The interface to all functions in this driver is implemented via ioctls
> on files exposed through a filesystem called 'k
On 01/20/2015 09:25 AM, Daniel Mack wrote:
> Hi Michael,
>
> On 01/20/2015 09:09 AM, Michael Kerrisk (man-pages) wrote:
>> On 11/30/2014 06:23 PM, Florian Weimer wrote:
>>> * David Herrmann:
>>>
On Sun, Nov 30, 2014 at 10:02 AM, Florian Weimer
wrote:
> * Greg Kroah-Hartman:
>
>
Hi Michael,
On 01/20/2015 09:09 AM, Michael Kerrisk (man-pages) wrote:
> On 11/30/2014 06:23 PM, Florian Weimer wrote:
>> * David Herrmann:
>>
>>> On Sun, Nov 30, 2014 at 10:02 AM, Florian Weimer wrote:
* Greg Kroah-Hartman:
> +7.4 Receiving messages
>>
What happens if this is
Daniel, David,
On 11/30/2014 06:23 PM, Florian Weimer wrote:
> * David Herrmann:
>
>> On Sun, Nov 30, 2014 at 10:02 AM, Florian Weimer wrote:
>>> * Greg Kroah-Hartman:
>>>
+7.4 Receiving messages
>
>>> What happens if this is not possible because the file descriptor limit
>>> of the proce
From: Daniel Mack
kdbus is a system for low-latency, low-overhead, easy to use
interprocess communication (IPC).
The interface to all functions in this driver is implemented via ioctls
on files exposed through a filesystem called 'kdbusfs'. The default
mount point of kdbusfs is /sys/fs/kdbus. Th
* David Herrmann:
> On Sun, Nov 30, 2014 at 10:02 AM, Florian Weimer wrote:
>> * Greg Kroah-Hartman:
>>
>>> +7.4 Receiving messages
>> What happens if this is not possible because the file descriptor limit
>> of the processes would be exceeded? EMFILE, and the message will not
>> be received?
>
* David Herrmann:
> poll(2) and friends cannot return data for changed descriptors. I
> think a single trap for each KDBUS_CMD_MSG_RECV is acceptable. If this
> turns out to be a bottleneck, we can provide bulk-operations in the
> future. Anyway, I don't see how a _shared_ pool would change any of
Hi
On Sun, Nov 30, 2014 at 9:56 AM, Florian Weimer wrote:
> * Greg Kroah-Hartman:
>
>> +The focus of this document is an overview of the low-level, native kernel
>> D-Bus
>> +transport called kdbus. Kdbus exposes its functionality via files in a
>> +filesystem called 'kdbusfs'. All communication
Hi
On Sun, Nov 30, 2014 at 10:02 AM, Florian Weimer wrote:
> * Greg Kroah-Hartman:
>
>> +7.4 Receiving messages
>
>> +Also, if the connection allowed for file descriptor to be passed
>> +(KDBUS_HELLO_ACCEPT_FD), and if the message contained any, they will be
>> +installed into the receiving proce
Hi
On Sun, Nov 30, 2014 at 10:08 AM, Florian Weimer wrote:
> * Andy Lutomirski:
>
>> At the risk of opening a can of worms, wouldn't this be much more
>> useful if you could share a pool between multiple connections?
>
> They would also be useful to reduce context switches when receiving
> data f
* Andy Lutomirski:
> At the risk of opening a can of worms, wouldn't this be much more
> useful if you could share a pool between multiple connections?
They would also be useful to reduce context switches when receiving
data from all kinds of descriptors. At present, when polling, you
receive no
* Greg Kroah-Hartman:
> +7.4 Receiving messages
> +Also, if the connection allowed for file descriptor to be passed
> +(KDBUS_HELLO_ACCEPT_FD), and if the message contained any, they will be
> +installed into the receiving process after the KDBUS_CMD_MSG_RECV ioctl
> +returns. The receiving task
* Greg Kroah-Hartman:
> +The focus of this document is an overview of the low-level, native kernel
> D-Bus
> +transport called kdbus. Kdbus exposes its functionality via files in a
> +filesystem called 'kdbusfs'. All communication between processes takes place
> +via ioctls on files exposed throu
On Wed, Nov 26, 2014 at 7:30 AM, Andy Lutomirski wrote:
> Then find a clean way that's gated on having the right /proc access,
> which is not guaranteed to exist on all of your eventual users'
> systems, and, if that access doesn't exist because the admin or
> sandbox designer has sensibly revoked
On Wed, Nov 26, 2014 at 3:55 AM, David Herrmann wrote:
> Hi
>
> On Mon, Nov 24, 2014 at 9:57 PM, Andy Lutomirski wrote:
>> On Mon, Nov 24, 2014 at 12:16 PM, David Herrmann
>> wrote:
>>> [snip]
> +6.5 Getting information about a connection's bus creator
> +---
Hi
On Mon, Nov 24, 2014 at 9:57 PM, Andy Lutomirski wrote:
> On Mon, Nov 24, 2014 at 12:16 PM, David Herrmann
> wrote:
>> [snip]
+6.5 Getting information about a connection's bus creator
+
+
+The KDBUS_CMD_BUS_CREATOR_I
On Mon, Nov 24, 2014 at 12:16 PM, David Herrmann wrote:
> Hi Andy!
>
> On Fri, Nov 21, 2014 at 6:12 PM, Andy Lutomirski wrote:
>> On Thu, Nov 20, 2014 at 9:02 PM, Greg Kroah-Hartman
>> wrote:
>>> From: Daniel Mack
>>>
>>> kdbus is a system for low-latency, low-overhead, easy to use
>>> interpro
Hi Andy!
On Fri, Nov 21, 2014 at 6:12 PM, Andy Lutomirski wrote:
> On Thu, Nov 20, 2014 at 9:02 PM, Greg Kroah-Hartman
> wrote:
>> From: Daniel Mack
>>
>> kdbus is a system for low-latency, low-overhead, easy to use
>> interprocess communication (IPC).
>>
>> The interface to all functions in th
On Thu, Nov 20, 2014 at 9:02 PM, Greg Kroah-Hartman
wrote:
> From: Daniel Mack
>
> kdbus is a system for low-latency, low-overhead, easy to use
> interprocess communication (IPC).
>
> The interface to all functions in this driver is implemented through
> ioctls on files exposed through the mount
On 21.11.2014 06:02, Greg Kroah-Hartman wrote:
> From: Daniel Mack
> …
> +5.4 Creating buses and endpoints
> +
> +
> +KDBUS_CMD_BUS_MAKE, and KDBUS_CMD_ENDPOINT_MAKE take a
> +struct kdbus_cmd_make argument.
> +
> +struct kdbus_cmd_make {
> + __u64 size;
> +Th
From: Daniel Mack
kdbus is a system for low-latency, low-overhead, easy to use
interprocess communication (IPC).
The interface to all functions in this driver is implemented through
ioctls on files exposed through the mount point of a kdbusfs. This
patch adds detailed documentation about the ke
On Thu, Oct 30, 2014 at 01:20:23PM +0100, Peter Meerwald wrote:
>
> > kdbus is a system for low-latency, low-overhead, easy to use
> > interprocess communication (IPC).
> >
> > The interface to all functions in this driver is implemented through ioctls
> > on /dev nodes. This patch adds detailed
> kdbus is a system for low-latency, low-overhead, easy to use
> interprocess communication (IPC).
>
> The interface to all functions in this driver is implemented through ioctls
> on /dev nodes. This patch adds detailed documentation about the kernel
> level API design.
just some typos below
From: Daniel Mack
kdbus is a system for low-latency, low-overhead, easy to use
interprocess communication (IPC).
The interface to all functions in this driver is implemented through ioctls
on /dev nodes. This patch adds detailed documentation about the kernel
level API design.
Signed-off-by: D
77 matches
Mail list logo
