Julius Volz wrote:
Thanks. I've now looked closer at Netlink and read the Genetlink implementation. For the new IPVS interface, is there a preference for the granularity of the top-level Genetlink operations? I see three naive possibilities (one Genetlink op per line), if we start out with a straight mapping from the old API to the new one: a) SET - covers all of previous IP_VS_SO_SET_* GET - covers all of previous IP_VS_SO_GET_* b) more split up ADD - services and destinations EDIT - services and destinations DEL - services and destinations SETTIMEOUT STARTDAEMON STOPDAEMON ZERO (+ granular GET commands...) c) totally split up ADD_SVC ADD_DEST EDIT_SVC EDIT_DEST DEL_SVC DEL_DEST SETTIMEOUT STARTDAEMON STOPDAEMON ZERO (+ granular GET commands...) I find http://www.linuxfoundation.org/en/Net:Generic_Netlink_HOWTO saying: =========================== Operation Granularity While it may be tempting to register a single operation for a Generic Netlink family and multiplex multiple sub-commands on the single operation, this is strongly discouraged for security reasons. Combining multiple behaviors into one operation makes it difficult to restrict the operations using the existing Linux kernel security mechanisms. =========================== Option c) looks reasonable to me and also seems easy to handle in general. Is this the way to go? Or do we want the interface to look completely different this time?
b) or c) both look fine. You could save a few operations (ADD/EDIT can be combined) by making use of nlmsg_flags though: The semantics of the flags is: - NLM_F_CREATE|NLM_F_EXCL: create if non-existant - NLM_F_REPLACE: change existing - NLM_F_CREATE|NLM_F_REPLACE: create if non-existing, replace otherwise - NLM_F_EXCL: test existance NLM_F_APPEND can be used as modifier for NLM_F_CREATE to specify that the new entry should be added to the end instead of the beginning. -- 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
