netdev - Re: [PATCH 2/2] IPVS: Add genetlink interface implementation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f4845fc0807100813o65dee75bgfc53a395dccf74f6@mail.gmail.com>
Date:	Thu, 10 Jul 2008 17:13:39 +0200
From:	"Julius Volz" <juliusv@...gle.com>
To:	"Thomas Graf" <tgraf@...g.ch>
Cc:	"Patrick McHardy" <kaber@...sh.net>, netdev@...r.kernel.org,
	lvs-devel@...r.kernel.org, vbusam@...gle.com, horms@...ge.net.au,
	davem@...emloft.net
Subject: Re: [PATCH 2/2] IPVS: Add genetlink interface implementation

On Thu, Jul 10, 2008, Thomas Graf wrote:
> * Julius Volz <juliusv@...gle.com> 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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html