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
>
On Feb 4, 2015 4:16 PM, David Herrmann dh.herrm...@gmail.com wrote:
Hi
On Thu, Feb 5, 2015 at 12:03 AM, Andy Lutomirski l...@amacapital.net wrote:
I see latencies of around 20 microseconds with lockdep and context
tracking off. For example:
Without metadata nor memfd transmission, I get
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
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
On Tue, Feb 3, 2015 at 2:09 AM, Daniel Mack dan...@zonque.org wrote:
Hi Andy,
On 02/02/2015 09:12 PM, Andy Lutomirski wrote:
On Feb 2, 2015 1:34 AM, Daniel Mack dan...@zonque.org wrote:
That's right, but again - if an application wants to gather this kind of
information about tasks it
Hi
On Thu, Feb 5, 2015 at 12:03 AM, Andy Lutomirski l...@amacapital.net 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
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,
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
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
Greg Kroah-Hartman gre...@linuxfoundation.org writes:
On Tue, Feb 03, 2015 at 08:47:51PM -0600, Eric W. Biederman wrote:
Andy Lutomirski l...@amacapital.net writes:
On Tue, Feb 3, 2015 at 2:09 AM, Daniel Mack dan...@zonque.org wrote:
Hi Andy,
On 02/02/2015 09:12 PM, Andy Lutomirski
Andy Lutomirski l...@amacapital.net writes:
On Tue, Feb 3, 2015 at 2:09 AM, Daniel Mack dan...@zonque.org wrote:
Hi Andy,
On 02/02/2015 09:12 PM, Andy Lutomirski wrote:
On Feb 2, 2015 1:34 AM, Daniel Mack dan...@zonque.org wrote:
That's right, but again - if an application wants to gather
On Tue, Feb 03, 2015 at 08:47:51PM -0600, Eric W. Biederman wrote:
Andy Lutomirski l...@amacapital.net writes:
On Tue, Feb 3, 2015 at 2:09 AM, Daniel Mack dan...@zonque.org wrote:
Hi Andy,
On 02/02/2015 09:12 PM, Andy Lutomirski wrote:
On Feb 2, 2015 1:34 AM, Daniel Mack
On Tue, Feb 3, 2015 at 2:09 AM, Daniel Mack dan...@zonque.org wrote:
Hi Andy,
On 02/02/2015 09:12 PM, Andy Lutomirski wrote:
On Feb 2, 2015 1:34 AM, Daniel Mack dan...@zonque.org wrote:
That's right, but again - if an application wants to gather this kind of
information about tasks it
Hi Andy,
On 02/02/2015 09:12 PM, Andy Lutomirski wrote:
On Feb 2, 2015 1:34 AM, Daniel Mack dan...@zonque.org 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.
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
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 Feb 2, 2015 1:34 AM, Daniel Mack dan...@zonque.org wrote:
Hi Andy,
On 01/29/2015 01:09 PM, Andy Lutomirski wrote:
On Jan 29, 2015 6:42 AM, Daniel Mack dan...@zonque.org wrote:
As we explained before, currently, D-Bus peers do collect the same
information already if they need to have
Hi Andy,
On 01/29/2015 01:09 PM, Andy Lutomirski wrote:
On Jan 29, 2015 6:42 AM, Daniel Mack dan...@zonque.org 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
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.
>
> >
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
>
Hi Andy,
On 01/27/2015 05:03 PM, Andy Lutomirski wrote:
On Tue, Jan 27, 2015 at 7:05 AM, David Herrmann dh.herrm...@gmail.com 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
On 01/29/2015 12:25 PM, Andy Lutomirski wrote:
On Jan 29, 2015 3:53 AM, Daniel Mack dan...@zonque.org 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
On Jan 29, 2015 6:42 AM, Daniel Mack dan...@zonque.org wrote:
On 01/29/2015 12:25 PM, Andy Lutomirski wrote:
On Jan 29, 2015 3:53 AM, Daniel Mack dan...@zonque.org 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,
On Jan 29, 2015 3:53 AM, Daniel Mack dan...@zonque.org wrote:
Hi Andy,
On 01/27/2015 05:03 PM, Andy Lutomirski wrote:
On Tue, Jan 27, 2015 at 7:05 AM, David Herrmann dh.herrm...@gmail.com
wrote:
A 16byte copy does not affect the performance of kdbus message
transactions in any way
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
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-marshaling,
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
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
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
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
>>>
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
On Mon, Jan 26, 2015 at 3:46 PM, Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com 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
Hi
On Mon, Jan 26, 2015 at 5:45 PM, Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com wrote:
On 01/26/2015 04:26 PM, Tom Gundersen wrote:
On Mon, Jan 26, 2015 at 3:42 PM, Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com wrote:
2. Is the API to be invoked directly by applications or is
On Tue, Jan 27, 2015 at 7:05 AM, David Herrmann dh.herrm...@gmail.com wrote:
Hi
On Mon, Jan 26, 2015 at 3:46 PM, Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com 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
On 01/27/2015 04:23 PM, David Herrmann wrote:
Hi
On Mon, Jan 26, 2015 at 5:45 PM, Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com wrote:
On 01/26/2015 04:26 PM, Tom Gundersen wrote:
On Mon, Jan 26, 2015 at 3:42 PM, Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com wrote:
2. Is the API
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)
mtk.manpa...@gmail.com 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
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
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,
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
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
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)
mtk.manpa...@gmail.com 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
Hi Michael,
On Mon, Jan 26, 2015 at 3:42 PM, Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com 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
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
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 they
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,
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 dan...@zonque.org
kdbus is a system for low-latency,
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
>
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
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,
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
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
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 dan...@zonque.org
kdbus is a system for low-latency,
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)
mtk.manpa...@gmail.com wrote:
On 01/21/2015 05:58 PM, Daniel Mack wrote:
Also, the context the kdbus commands operate on originate from a
mountable
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 dan...@zonque.org
kdbus is a system for low-latency, low-overhead, easy to use
interprocess communication (IPC).
The interface to
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
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 of API
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
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
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
Hi Michael
On Thu, Jan 22, 2015 at 11:18 AM, Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com 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
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 about kdbus,
On 2015-01-22 08:46, David Herrmann wrote:
Hi Michael
On Thu, Jan 22, 2015 at 11:18 AM, Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com 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
On Fri, Jan 16, 2015 at 11:16:05AM -0800, Greg Kroah-Hartman wrote:
From: Daniel Mack dan...@zonque.org
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
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
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
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
>>>
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
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
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,
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:
* kdbus
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)
mtk.manpa...@gmail.com wrote:
On 01/16/2015 08:16 PM, Greg Kroah-Hartman wrote:
From: Daniel Mack dan...@zonque.org
kdbus is a system for low-latency,
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 syscall
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 we
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 receiving
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, Michael
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 dan...@zonque.org
[...]
+offset field contains the location of the new message inside the receiver's
+pool. The message is stored as struct kdbus_msg at
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
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
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
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
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
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
>>>
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
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
On 01/16/2015 08:16 PM, Greg Kroah-Hartman wrote:
From: Daniel Mack dan...@zonque.org
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
On 01/16/2015 08:16 PM, Greg Kroah-Hartman wrote:
From: Daniel Mack dan...@zonque.org
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
1 - 100 of 110 matches
Mail list logo
