<div dir="ltr"><div><div>Hi<br></div><div><br>I'm forwarding the patch as I received it (with the name of the author, but I'd wait for his consent before disclosing his other info although just in case).<br><br></div>
In fact, the functions therein don't touch the functionality of the master. In other words if you don't use those functions, it doesn't absolutely incur any penalty whatsoever (except perhaps an extra `case` in `ioctl` which I think we can all agree is negligible). The functions themselves are very simple and simply just loop over the domains and tell whether they are received.<br>
<i><br></i>Here's how it's tested (quoting from the past):<br><br></div><i>--- quote ---<br></i><div><i></i><div><div><i>Alright, I did the test with the following configuration:<br><br>2 
slaves, each producing 1.2k data, split equally in 2 datagrams. A bridge
 placed in the network that introduces a delay between the 2 datagrams. 
The delays I tested with were 100us, 500us and 1ms. That is, the bridge 
makes sure there is at least 1ms delay between passing frames. I logged 
the passing times and this is done correctly.<br>
<br>Now, with <b><span style="font-family:courier new,monospace">ecrt_domain_received</span></b>,
 I could see that it returns true after a correct time. That is, when I 
increase the gap in the bridge, the receive time in the network is 
increased. With another program I checked the data <span class="">received</span> from the slaves and they are correct (both datagrams arrive).<br>
<br>So I guess everything works just fine! :)<br><br>Thank you for this patch, hope it makes its way to the official release.<span class=""><font color="#888888"><br>Shahbaz<br></font></span><br>P.S. You had forgot the EXPORT_SYMBOL in your patch (just in case you wanted to give it to the developers)</i><br>
</div><div><i>--- /quote ---</i><br><br></div><div>Furthermore, a peculiarity that I discovered is (quoted from another email):<br><br></div><div><i>--- quote ---<br>Something you might want to know:<br><br>If <b>ecrt_domain_received</b> is called after <b>ecrt_domain_process</b>, the kernel crashes. I did so to only read data of <span class="">received</span> domains (after I had processed them) only to discover this behavior.<br>
</i>
<i><br>No big deal though, as I can just read whatever is available and I don't really gain much by ignoring timed-out domains.<br></i></div><div><i>--- /quote ---<br></i></div><div><br></div><div>There was a long discussion on this and it was also reminded at another time. You can read the whole discussion here:<br>
<br><a href="http://lists.etherlab.org/pipermail/etherlab-users/2011/date.html">http://lists.etherlab.org/pipermail/etherlab-users/2011/date.html</a><br></div><div>(search for "Knowing when the packet"...)</div>
<div><br></div><div>and at a later time:<br></div><div><br><a href="http://lists.etherlab.org/pipermail/etherlab-users/2012/001755.html">http://lists.etherlab.org/pipermail/etherlab-users/2012/001755.html</a><br><a href="http://lists.etherlab.org/pipermail/etherlab-users/2012/001756.html">http://lists.etherlab.org/pipermail/etherlab-users/2012/001756.html</a><br>
</div><div><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Jun Yuan</b><br><br>patch file for stable 1.5 ;)<br><div class=""><div class="h5"><br></div></div><span class=""><font color="#888888">-- <br>
Jun Yuan</font></span><br></div><br></div></div></div></div>