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
