<div dir="ltr">Hi,<br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 18, 2018 at 8:48 PM, Christian Mauderer <span dir="ltr"><<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">Am 18.03.2018 um 14:22 schrieb Udit agarwal:<br>
> Hi all,<br>
> Here's the link to my proposal:<br>
> <a href="https://docs.google.com/document/d/15Ut9FLAV3Y0Up1Qn02ys6KAb2QhtReF_P-wNR861NMo/edit?usp=sharing" rel="noreferrer" target="_blank">https://docs.google.com/<wbr>document/d/<wbr>15Ut9FLAV3Y0Up1Qn02ys6KAb2QhtR<wbr>eF_P-wNR861NMo/edit?usp=<wbr>sharing</a><br>
><br>
> Please have a look, and comment where ever needed.<br>
> I tried my best to make time-line as realistic as possible. Please feel<br>
> free to comment in case of any unbalance or overlooked task.<br>
><br>
> Regards,<br>
> Udit agarwal<br>
><br>
><br>
<br>
</div></div>Hello Udit,<br>
<br>
some (not too well sorted) notes:<br>
<br>
1. One point I'm missing is the target that you produce a set of patches<br>
that can be easily merged as soon as the libbsd receives it's next<br>
update. Otherwise the only result from that project would be the<br>
comparison document.<br>
<br></blockquote><div>That's a really good idea! I have now included that in my proposal, please have a look. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2. I'm not sure whether the point<br>
<br>
  "Backport the SDIO driver residing within the mmccam stack to FreeBSD<br>
version being used by libbsd"<br>
<br>
is a good idea. It sounds like you want to do the backport on FreeBSD.<br>
You most likely would have a lot of work with that without any really<br>
useful results. It would be better to analyse whether some other<br>
subsystems might have an influence on the performance measurement (which<br>
I would expect to be quite few) and then do the backport directly on<br>
RTEMS libbsd.<br>
<br></blockquote><div>Noted. I have corrected this. Moreover, i am studying several <a href="http://blog.uditagarwal.in/index.php/2018/03/19/implementing-a-mmc-sd-sdio-stack-using-cam-framework/">files</a> changed/modified during<br></div><div>the mmccam commit and as of now, i didn't  came across any such Non-RTEMS dependency<br></div><div>that might affect systems performance. I have a query here, in <a href="https://github.com/RTEMS/rtems-libbsd/tree/master/freebsd/sys/cam">RTEMS-libbsd</a> cam directory, there are some files<br></div><div>like cam.h and cam_ccb.h belonging to different FreeBSD head versions. Is it because, since there has been no change in the file, so its not updated?<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
3. It seems that you have split up the test bench over all three phases.<br>
It might would be more efficient to search a test bench and get it<br>
running on FreeBSD as well as on RTEMS quite early. There should be no<br>
difference whether it runs on the old SD-card driver, the SDIO one or<br>
some USB stick. It should basically work with with any block device.<br>
<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If you start to port it to RTEMS in phase 3 and then find out that it<br>
doesn't work like expected, you will have to restart with searching some<br>
other test bench. This would mean that you can throw away all results of<br>
the workbench that you collected in between.<br>
<br></blockquote><div>I have corrected this. So, now the first phase, I'll be porting SDIO driver, and in the second and third phase, I'll focus on the benchmarking task. Hopefully, now we have ample time to fallback and search for another benchmarks in case the first one didn't work expectedly.  <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
4. I'm not quite sure whether the amount of work would really fill all<br>
three phases. Maybe you should plan an extended goal. With that topic<br>
that could for example be a benchmark for some other drivers (like USB<br>
storage).<br>
<br></blockquote><div>Done. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
5. Currently your results are a document and a set of patches that<br>
(hopefully) can be integrated into libbsd in the future. I think that if<br>
you find some good standard performance test for block devices, porting<br>
that could be another core result that can be integrated directly and<br>
not only after a libbsd upgrade.<br>
<br></blockquote><div>I came across several popular, multipurpose I/O benchmarks like IOZone and IOrate with compatible license(<a href="http://www.iozone.org/docs/Iozone_License.txt">1</a>,<a href="https://sites.google.com/site/vwiorate/home">2</a>). Since, these are FreeBSD compatible probably they will work. Still, I have added 'Searching and testing benchmarks on FreeBSD' as one of my goal. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
With kind regards<br>
<span class="HOEnZb"><font color="#888888"><br>
Christian Mauderer<br>
</font></span></blockquote></div><br></div><div class="gmail_extra">Regards,<br></div><div class="gmail_extra">Udit agarwal<br></div></div>