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
* 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
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
20 matches
Mail list logo
