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 ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
