|
On Thu, Jul 10, 2008, Thomas Graf wrote:
> * Julius Volz <juliusv@xxxxxxxxxx> 2008-07-10 14:33
>> Note that I use different first level attributes depending on the
>> command. Rather than calculating the largest needed size, it's
>> probably best to join all attributes that may ever occur in the first
>> level into one big enum, right?
>
> Yes, that's the easiest solution and it doesn't really cost you
> anything besides the slightly bigger allocation.
Yes.
>> > Typically, netlink code follows the following semantics WRT to
>> > commands/message types:
>> > -> GET_SERVICE (NLM_F_DUMP)
>> > <- NEW_SERVICE
>> > <- NEW_SERVICE
>> > <- NEW_SERVICE
>>
>> Ok, so I will set the answer message type to IPVS_CMD_NEW_SERVICE (and
>> accordingly in the other dump cases). For non-dump GET commands, is it
>> usual to have the response ID be the same as the request?
>
> It should follow the same semantics as with dumps. Netlink is typically
> used in an object context, where objects are requested, added or deleted.
> Basically, a dump is a request to fill the userspace listening part with
> all objects of the specified type. genetlink is a bit special as it
> moved away from the traditional 4 commands per family (get, new, set,
> delete) but in a case like IPVS where you are in fact managing objects
> it does make sense to stick to the known semantics.
So, just to be sure: when I'm not returning an object (like in
IPVS_CMD_GET_INFO), I still use IPVS_CMD_GET_INFO as the command ID in
the response? This is also how net/irda/irnetlink.c does it, but maybe
I'm copying bad examples again.
But whenever a response message is about objects, be it one or
multiple entries, I use the IPVS_CMD_NEW_* response IDs.
Julius
--
Google Switzerland GmbH
--
To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|
