All of lore.kernel.org
 help / color / mirror / Atom feed
From: Denis Kenzior <denkenz@gmail.com>
To: ell@lists.01.org
Subject: Re: [PATCH v2 08/11] dbus: Fix the kdbus message encoding
Date: Tue, 12 Apr 2016 18:30:19 -0500	[thread overview]
Message-ID: <570D850B.5060704@gmail.com> (raw)
In-Reply-To: <CAOq732+=aS_EtjWyOY5m0RDVBjgw7MwPwD27F5a1FoXi36QyKg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1209 bytes --]

Hi Andrew

On 04/12/2016 06:11 PM, Andrzej Zaborowski wrote:
> On 13 April 2016 at 01:06, Andrzej Zaborowski
> <andrew.zaborowski@intel.com> wrote:
>> On 13 April 2016 at 00:25, Denis Kenzior <denkenz@gmail.com> wrote:
>>> Can we special case the building of this variant for gvariant based
>>> messages?  Similar to how we're generating the signature on the fly in the
>>> builder?
>>
>> Is it worth it though, just to save a memcpy?
>
> BTW we still need to add the offset after the variant, which is the
> header size, so it wouldn't save the memcpy.
>

Yikes, these people are more insane than I thought ;)

Why do they insist on:
"When transmitting over kdbus, the entire content of the header (all 
parts up to and including the extended header dictionary) must be 
transmitted inside of the first payload item (either vector or memfd). 
The content may be merged with the body (or part of the body) into the 
same item, but the entire header must appear entirely within the first 
item. "

If the actual field length is only known WAAAY later?

Anyway, can we add the offsets inside builder_finalize again.  Or 
alternatively as a separate KDBUS_ITEM?

Regards,
-Denis

  reply	other threads:[~2016-04-12 23:30 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-12  1:56 [PATCH v2 01/11] dbus: Validate field type in get_header_field Andrew Zaborowski
2016-04-12  1:56 ` [PATCH v2 02/11] dbus: Check some more return values when parsing messages Andrew Zaborowski
2016-04-12 18:53   ` Denis Kenzior
2016-04-12  1:56 ` [PATCH v2 03/11] dbus: GVariant header field identifiers are 64-bit Andrew Zaborowski
2016-04-12  1:56 ` [PATCH v2 04/11] dbus: Fix parsing GVariant header/body information Andrew Zaborowski
2016-04-12 21:15   ` Denis Kenzior
2016-04-12  1:56 ` [PATCH v2 05/11] dbus: GVariant message cookie and reply cookie are 64-bit Andrew Zaborowski
2016-04-12 21:18   ` Denis Kenzior
2016-04-12 22:00     ` Andrzej Zaborowski
2016-04-12  1:56 ` [PATCH v2 06/11] dbus: Don't rely on 1st KDBUS_ITEM_PAYLOAD_OFF being the header Andrew Zaborowski
2016-04-12  1:56 ` [PATCH v2 07/11] gvariant: Utility to build GVariant message out of header+body Andrew Zaborowski
2016-04-12 21:44   ` Denis Kenzior
2016-04-12 22:06     ` Andrzej Zaborowski
2016-04-12  1:56 ` [PATCH v2 08/11] dbus: Fix the kdbus message encoding Andrew Zaborowski
2016-04-12 21:46   ` Denis Kenzior
2016-04-12 22:10     ` Andrzej Zaborowski
2016-04-12 22:25       ` Denis Kenzior
2016-04-12 23:06         ` Andrzej Zaborowski
2016-04-12 23:11           ` Andrzej Zaborowski
2016-04-12 23:30             ` Denis Kenzior [this message]
2016-04-12 23:18           ` Denis Kenzior
2016-04-12 23:30             ` Andrzej Zaborowski
2016-04-12 23:42               ` Denis Kenzior
2016-04-13  0:14               ` Denis Kenzior
2016-04-13  0:23                 ` Andrzej Zaborowski
2016-04-12  1:56 ` [PATCH v2 09/11] dbus: Rename _dbus_header_is_valid to _dbus1_header_is_valid Andrew Zaborowski
2016-04-12  1:56 ` [PATCH v2 10/11] gvariant: Fix empty structure/array parsing and error check Andrew Zaborowski
2016-04-12  1:56 ` [PATCH v2 11/11] unit: Fix GVariant test messages Andrew Zaborowski
2016-04-12 18:51 ` [PATCH v2 01/11] dbus: Validate field type in get_header_field Denis Kenzior

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=570D850B.5060704@gmail.com \
    --to=denkenz@gmail.com \
    --cc=ell@lists.01.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.