[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <383f66ae460548de6f930b0f1c244e5a@amnesiak.org>
Date: Thu, 25 Oct 2012 16:49:28 +0200
From: Tony Cheneau <tony.cheneau@...esiak.org>
To: Alexander Smirnov <alex.bluesman.smirnov@...il.com>
Cc: "David S. Miller" <davem@...emloft.net>, <netdev@...r.kernel.org>,
<linux-zigbee-devel@...ts.sourceforge.net>,
Alan Ott <alan@...nal11.us>
Subject: Re: [PATCH net-next 00/15] 6lowpan: Some more bug fixes
Hello Alexander,
Thank you for your comments. See my answer inline.
Le 25.10.2012 06:52, Alexander Smirnov a écrit :
> Hi,
>
[...]
> 1. The series is quite huge what makes it difficult for the review.
> It
> would be better to split it into one-two and submit separately (not
> simultaneously).
OK. Will do.
> 2. Could you also please provide some notes about how have you tested
> these changes (logs, plain text)? Do I need to check your changes
> locally on my desk? If so I need some instructions.
I'm not sure what you are asking here. There was some more debugging
printk, that I removed because they were too verbose. Mostly, I test my
patch with few userspace program, like ping6, iperf (both for TCP and
UDP) and ssh. I also wrote a TCP and a UDP echo server, so as to test
fragmentation in more details. For most functional patches, I usually
confirm through wireshark that the packets indeed look the way they
should (this, I've done it for patch 11 for example). But I don't have
any automated scripts to check for regression. I can provide you the
script I use to configure nodes if needed (but it pretty straighward and
should look like your own scripts).
I'm not sure that really answers your question.
> 3. Please DO NOT submit patches like: this patch fixes blablabla
> which
> isn't in the kernel yet (like patch 13,15). I have no clue what you
> have locally on your laptop and what you will send in some time. I'd
> like to see here the working code, not a references to TBD.
I'm OK with removing patch 13 (I'll introduce it alongside the serial
driver later on). I'm not so OK with removing patch 15, or at least, it
would require some more testing in other parts of the code. Basically,
the TBD are placeholder for when the Association Request/Response will
be reimplemented. I introduced it because otherwise, .assoc_req and
.assoc_resp entries of mac802154_mlme_wpan would go uninitialized and
would cause kernel crash when called. I could have modified the calling
code to deal with that, but I thought these primitives were meant to be
re-implemented soon anyway.
> 4. The reference to linux-zigbee project isn't an occasion for me to
> apply this code to this tree. I have no goal to merge all this fun to
> mainline due to several things in linux-zigbee kernel work NOT
> according to the standard (mostly it's a timing problems) and global
> refactoring needed.
I don't understand what you are talking about here. I would guess that
you are talking about patch 15. If so, my answer is the following, while
I understand your effort to refactor linux-zigbee code and fix things
along the way, some code went through net-next that cause crashes. My
pragmatic approach is to try to fix it before more people use it, even
through it might not always be the most elegant way to do it.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists