From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755569Ab2AYG3d (ORCPT ); Wed, 25 Jan 2012 01:29:33 -0500 Received: from mail-wi0-f174.google.com ([209.85.212.174]:53786 "EHLO mail-wi0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751833Ab2AYG3c (ORCPT ); Wed, 25 Jan 2012 01:29:32 -0500 Message-ID: <1327472968.14373.41.camel@edumazet-laptop> Subject: Re: [patch v3, kernel version 3.2.1] Source mode for macvlan interface From: Eric Dumazet To: =?UTF-8?Q?=C5=A0tefan?= Gula Cc: David Miller , kaber@trash.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Date: Wed, 25 Jan 2012 07:29:28 +0100 In-Reply-To: References: <12446987.2261327416407141.JavaMail.root@5-MeO-DMT.ynet.sk> <25119746.2341327416953583.JavaMail.root@5-MeO-DMT.ynet.sk> <20120124.230354.1696063062900108959.davem@davemloft.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.2- Content-Transfer-Encoding: 8bit Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le mercredi 25 janvier 2012 à 07:22 +0100, Štefan Gula a écrit : > It's a result of need to have enough space allocated for sk_buff > struct before called macvlan_fill_info. I know that it looks somehow > messy. BUt before the macvlan_fill_info is called there is only one > procedure calcit. The problem of calcit is that it doesn't have access > to struct net_device *dev int it. It has only access to struct sk_buff > *skb, so from that point it cannot be called directly (whole parsing > code had to be copied there to get the *dev a calling > if_nlmsg_size(dev) from it. On the other hand calcit returns global > static value of min_ifinfo_dump_size and that is shared among all > interfaces and modifying like this do the job properly. There was > another different way and that was creating and registering a whole > new PF_MACLVAN netlink group resulting in copying almost 95% percent > of given code and modified it somehow to do the same. > > If it should be result of separate commitment than ok, but it was > result apparently of need only for use of macvlan that's why it was > included in my patch. > > So how should I proceed with it? A separate patch for this part, as David said ? The intent is to catch people attention on a particular point, instead of unnoticed code in some huge unrelated patch.