From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Julius Volz" Subject: Re: [PATCH 00/26] IPVS: Add first IPv6 support to IPVS. Date: Mon, 16 Jun 2008 02:14:00 +0200 Message-ID: References: <20080612014548.GE22358@verge.net.au> <485126BD.7030109@trash.net> <485144DF.3030102@trash.net> <20080613062621.GA10474@verge.net.au> <48528EED.7090307@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Simon Horman" , "Vince Busam" , "Ben Greear" , lvs-devel@vger.kernel.org, netdev@vger.kernel.org To: "Patrick McHardy" Return-path: Received: from smtp-out.google.com ([216.239.33.17]:32407 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751069AbYFPAOG (ORCPT ); Sun, 15 Jun 2008 20:14:06 -0400 Received: from zps37.corp.google.com (zps37.corp.google.com [172.25.146.37]) by smtp-out.google.com with ESMTP id m5G0E1GL012599 for ; Mon, 16 Jun 2008 01:14:02 +0100 Received: from wf-out-1314.google.com (wfc25.prod.google.com [10.142.3.25]) by zps37.corp.google.com with ESMTP id m5G0DwWi020763 for ; Sun, 15 Jun 2008 17:14:01 -0700 Received: by wf-out-1314.google.com with SMTP id 25so5115299wfc.14 for ; Sun, 15 Jun 2008 17:14:00 -0700 (PDT) In-Reply-To: <48528EED.7090307@trash.net> Content-Disposition: inline Sender: netdev-owner@vger.kernel.org List-ID: On Fri, Jun 13, 2008 at 5:14 PM, Patrick McHardy wrote: > Julius Volz wrote: >> As for compatibility and extensibility, how is that best achieved with >> netlink? I've seen some examples copy whole C structs into netlink >> datagrams, but that is obviously what we don't want anymore. So the >> way to go seems to be to transfer each struct field as a separate >> netlink attribute, right? > > Yes. You can also group those which belong together logically > in nested attributes. 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? Julius -- Google Switzerland GmbH