From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: [PATCH 00/26] IPVS: Add first IPv6 support to IPVS. Date: Fri, 13 Jun 2008 17:14:53 +0200 Message-ID: <48528EED.7090307@trash.net> References: <485043E6.5030105@candelatech.com> <485050FE.6030209@google.com> <20080612014548.GE22358@verge.net.au> <485126BD.7030109@trash.net> <485144DF.3030102@trash.net> <20080613062621.GA10474@verge.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: Simon Horman , Vince Busam , Ben Greear , lvs-devel@vger.kernel.org, netdev@vger.kernel.org To: Julius Volz Return-path: In-Reply-To: Sender: lvs-devel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org Julius Volz wrote: > On Fri, Jun 13, 2008 at 8:26 AM, Simon Horman wrote: >> I don't really have any concrete ideas about what a better >> interface would look like. But I am more than happy to hash our ideas. > > Good! At the moment I'm looking at various netlink docs and figuring > out how things generally work. I think netlink probably adds a lot of > complexity over the previous sockopt interface, but I hope it's worth > it. > > 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.