From: Thomas Graf <tgraf@suug.ch>
To: Julius Volz <juliusv@google.com>
Cc: Patrick McHardy <kaber@trash.net>,
netdev@vger.kernel.org, lvs-devel@vger.kernel.org,
vbusam@google.com, horms@verge.net.au, davem@davemloft.net
Subject: Re: [PATCH 2/2] IPVS: Add genetlink interface implementation
Date: Thu, 10 Jul 2008 23:16:30 +0200 [thread overview]
Message-ID: <20080710211630.GW20815@postel.suug.ch> (raw)
In-Reply-To: <f4845fc0807100813o65dee75bgfc53a395dccf74f6@mail.gmail.com>
* Julius Volz <juliusv@google.com> 2008-07-10 17:13
> 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.
Personally I would never use a GET id to send any data at all. My main
focus is on trying to make message protocols self documenting. If a
certain message type has multiple meanings depending on the direction
it will make it harder to understand and harder to debug from a protocol
standpoint.
The common netlink semantics are
CMD_OBJ_NEW - create or update objects as described in the message
content.
CMD_OBJ_SET - rarely used, update a static object which doesn't have
to be created or added. asme as OBJ_NEW otherwise.
CMD_OBJ_DEL - delete object described in the message
CMD_OBJ_GET - search for a object as described in the message and
send a CMD_OBJ_NEW as reply including the full object.
with NLM_F_DUMP: iterate over all objects and send a
CMD_OBJ_NEW for each object. This request often carries
no additional data.
It's pretty simple but covers almost every possible protocol for use
in configuration interfaces. In the case of IPVS_CMD_GET_INFO the
actual data being sent back can be regarded as a info object. Basically
netlink is mainly used as a very basic form of rpc.
next prev parent reply other threads:[~2008-07-10 21:16 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-09 15:11 [PATCH 0/2] IPVS: Add Generic Netlink configuration interface Julius Volz
2008-07-09 15:11 ` [PATCH 1/2] IPVS: Add genetlink interface definitions to ip_vs.h Julius Volz
2008-07-09 15:11 ` [PATCH 2/2] IPVS: Add genetlink interface implementation Julius Volz
2008-07-09 15:17 ` YOSHIFUJI Hideaki / 吉藤英明
2008-07-09 15:24 ` Julius Volz
2008-07-09 16:43 ` Patrick McHardy
2008-07-09 18:16 ` Julius Volz
2008-07-10 12:15 ` Patrick McHardy
2008-07-10 13:58 ` Julius Volz
2008-07-10 14:43 ` Thomas Graf
2008-07-10 11:20 ` Julius Volz
2008-07-10 11:36 ` Thomas Graf
2008-07-10 12:33 ` Julius Volz
2008-07-10 14:41 ` Thomas Graf
2008-07-10 15:13 ` Julius Volz
2008-07-10 21:16 ` Thomas Graf [this message]
2008-07-10 23:16 ` Julius Volz
2008-07-16 12:15 ` Thomas Graf
2008-07-16 13:03 ` Julius Volz
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=20080710211630.GW20815@postel.suug.ch \
--to=tgraf@suug.ch \
--cc=davem@davemloft.net \
--cc=horms@verge.net.au \
--cc=juliusv@google.com \
--cc=kaber@trash.net \
--cc=lvs-devel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=vbusam@google.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).