All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
To: ell@lists.01.org
Subject: Re: [PATCH 2/4] genl: Add a message builder API to help creating complex nl messages
Date: Tue, 24 Mar 2015 10:12:28 +0200	[thread overview]
Message-ID: <55111C6C.8080203@linux.intel.com> (raw)
In-Reply-To: <550BDF83.3070303@linux.intel.com>

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

Hi Marcel,

>> do we really need a queue here? Can we not just store the latest 
>> offset. Also how do you do nested of nested attributes?
>
> Nested of nested exists, in nftables for instance.
> Unless we prefer to have a fixed depth of nested of nested (like 3, 
> 4...?),
> we need such dynamically allocated list.
>
> I haven't tested this case, but we have to handle it.
> Unless we plan to use that code for nl80211 only.
>
>>> +    }
>>> +
>>> +    // In case nothing has been appended into the nested attribute
>>> +    // it could try to be smart and revert the message back and 
>>> return true
>> this is not our comment style. Please respect the coding style.
>
> Actually, it's more like a question that needs an answer. I don't want 
> this comment to go in anyway.
> Or let's just forget entirely about this.
>
>>> +struct l_genl_msg *l_genl_msg_builder_finalize(
>>> +                    struct l_genl_msg_builder *builder);
>> So I saw that l_dbus_message_builder does a similar thing. We give in 
>> a message to start from and then we get that message back out when 
>> finalizing it. Has anything changed in between or why are we doing this?
>
> The rule was to follow what DBus API does. But I think it's useless:
> - l_genl_msg_builder_new()  it could take a size, and create the msg 
> internally. (or have a fixed size of 512bytes, and if really needed 
> would realloc relevantly?)
> - then if everything went well: l_genl_msg_builder_finalize() would 
> return a msg pointer (a reference of it actually), which one we could 
> use to send  (and send unref the msg).
>
> Less function to call from client code.
> It's actually awkward that you have to create the msg yourself, then 
> also a builder with it etc...
> when you have also other functions to append attributes directly in 
> the msg.
> At least in dbus api you can't append anything BUT through a builder.
> (So yes I don't want to follow the DBus Api but finally a bit anyway...)
>
> The naming is too long as well, l_genl_msg_builder_append_attribute() 
> mostly.
> Suggestions would be welcome. I can strip the "ibute" at the end at 
> least.
> And also msg_builder into _msgbld_ or does the lack of vowels makes it 
> even crappier?


Any comment on this?
Would be nice if I can solve all that, api and unit test, at once.

Tomasz

  reply	other threads:[~2015-03-24  8:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-10 11:14 [PATCH v2 0/4] Improve genl with a message builder Tomasz Bursztyka
2015-03-10 11:14 ` [PATCH 1/4] genl: Normilize functions exports and parameters check as it should Tomasz Bursztyka
2015-03-11  5:03   ` Denis Kenzior
2015-03-10 11:14 ` [PATCH 2/4] genl: Add a message builder API to help creating complex nl messages Tomasz Bursztyka
2015-03-18 17:24   ` Marcel Holtmann
2015-03-20  8:51     ` Tomasz Bursztyka
2015-03-24  8:12       ` Tomasz Bursztyka [this message]
2015-03-10 11:14 ` [PATCH 3/4] genl: Add a function to grab the message's raw data for unit purpose Tomasz Bursztyka
2015-03-10 11:14 ` [PATCH 4/4] unit: Add a message builder unit test for genl Tomasz Bursztyka
2015-03-18 17:24   ` Marcel Holtmann
2015-03-20 22:41   ` Marcel Holtmann
2015-03-24  6:55     ` Tomasz Bursztyka

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=55111C6C.8080203@linux.intel.com \
    --to=tomasz.bursztyka@linux.intel.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.