[systemd-devel] [PATCH 3/3] kdbus: get some creds during meta append for optimization

[Daniel Mack]

On 08/20/2014 06:16 PM, Djalal Harouni wrote:
> On Tue, Aug 19, 2014 at 09:15:35AM +0200, Daniel Mack wrote:

>> Hmm, I'm not convinced this buys us anything really. After all, that
>> struct has a single user only, and factoring out these fields doesn't
>> necessarily lead to more readability.
> Hmm with your commit 7bde48f293f5, I guess we have to add a generic
> struct like that, or split into multiple structs, the aim would be to
> share the struct and operations that perform the:
> 
> Translate and install fields into the receiver's slice when requesting 
> the connection info or when the receiver reads the message ?

Atm, I think the best way is to fully populate the items at creation
time, and override them again when installing the message. That way, we
at least make sure not to deliver bogus data in for connection info
calls at we get rid of the logical dependency between metadata and the
queue items. A long-hanging fruit for optimization would be to check the
namespaces at delivery time, and only patch over data if they differ.
That can still be done later.

> Well, yes without numbers the optimization for uid/gid perhaps is not
> needed, but for the auxgroup perhaps ? we can allocate and get the
> auxgrps one time, then just memdup the data into the queue->auxgrps[] ?

But their not necessarily equal in size. After all, in the final item,
all values are u64, so we have to walk the list again.

> Just trying to figure out the best solution...

Me too :)

> BTW Daniel, sorry for this stupid question:
> Can't the KDBUS_ATTACH_AUXGROUPS be part of the KDBUS_ATTACH_CREDS item?
> 
> Will be easy to parse it in the same item with uid/gid...

Hmm, I don't think so. We designed the metadata thing in a way that it
allows users to request individual items in a fine-grained way, and I'm
not convinced that every user who wants the creds item is also
interested in auxgrp information. The other way around, it might be
different story though.


Thanks,
Daniel