Return-Path: Subject: Re: [PATCHv2 bluetooth-next 00/10] 6lowpan: introduce basic 6lowpan-nd To: YOSHIFUJI Hideaki , Marcel Holtmann , "David S. Miller" References: <1461140382-4784-1-git-send-email-aar@pengutronix.de> <57354315.2050509@miraclelinux.com> Cc: linux-wpan@vger.kernel.org, kernel@pengutronix.de, Jukka Rissanen , hannes@stressinduktion.org, Stefan Schmidt , mcr@sandelman.ca, Werner Almesberger , Linux Bluetooth , Network Development , Alexey Kuznetsov , James Morris , Hideaki YOSHIFUJI , Patrick McHardy From: Alexander Aring Message-ID: Date: Fri, 13 May 2016 14:33:40 +0200 MIME-Version: 1.0 In-Reply-To: <57354315.2050509@miraclelinux.com> Content-Type: text/plain; charset=windows-1252 Sender: netdev-owner@vger.kernel.org List-ID: Hi, On 05/13/2016 04:59 AM, YOSHIFUJI Hideaki wrote: > Hi, > > Marcel Holtmann wrote: >> Hi Dave, > : >>> include/linux/netdevice.h | 6 +- >>> include/net/6lowpan.h | 24 ++ >>> include/net/addrconf.h | 3 + >>> include/net/ndisc.h | 124 ++++++++- >>> net/6lowpan/6lowpan_i.h | 2 + >>> net/6lowpan/Makefile | 2 +- >>> net/6lowpan/core.c | 50 +++- >>> net/6lowpan/iphc.c | 167 +++++++++-- >>> net/6lowpan/ndisc.c | 633 ++++++++++++++++++++++++++++++++++++++++++ >>> net/bluetooth/6lowpan.c | 2 + >>> net/ieee802154/6lowpan/core.c | 12 + >>> net/ieee802154/6lowpan/tx.c | 107 ++++--- >>> net/ipv6/addrconf.c | 7 +- >>> net/ipv6/ndisc.c | 132 +++++---- >>> net/ipv6/route.c | 4 +- >>> 15 files changed, 1117 insertions(+), 158 deletions(-) >>> create mode 100644 net/6lowpan/ndisc.c >> >> is there a chance that we get input into this patch set? I wonder also if it would be acceptable to take this through bluetooth-next or should it better go straight into net-next? > > The core idea of introducing ndisc_ops is okay, but I do think this > series of patches should be refactored; we should not make another > "copy" of core of ndisc logic. We can introduce "ops" for each > option, for example. > Thanks for your suggestion. I will try to make another patch series which introduce ops for each option. I also thinks it's better now. E.g. some days ago there was another question on netdev for doing more ndp_proxy stuff inside the kernel [0]. If such feature will be added later then both implementation would be touched (which almost introduce the same code). - Alex [0] http://marc.info/?l=linux-netdev&m=146278123414146