[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f1898362-7bf3-705b-d72a-289e81910be8@pengutronix.de>
Date: Fri, 13 May 2016 14:33:40 +0200
From: Alexander Aring <aar@...gutronix.de>
To: YOSHIFUJI Hideaki <hideaki.yoshifuji@...aclelinux.com>,
Marcel Holtmann <marcel@...tmann.org>,
"David S. Miller" <davem@...emloft.net>
Cc: linux-wpan@...r.kernel.org, kernel@...gutronix.de,
Jukka Rissanen <jukka.rissanen@...ux.intel.com>,
hannes@...essinduktion.org,
Stefan Schmidt <stefan@....samsung.com>, mcr@...delman.ca,
Werner Almesberger <werner@...esberger.net>,
Linux Bluetooth <linux-bluetooth@...r.kernel.org>,
Network Development <netdev@...r.kernel.org>,
Alexey Kuznetsov <kuznet@....inr.ac.ru>,
James Morris <jmorris@...ei.org>,
Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
Patrick McHardy <kaber@...sh.net>
Subject: Re: [PATCHv2 bluetooth-next 00/10] 6lowpan: introduce basic
6lowpan-nd
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
Powered by blists - more mailing lists