<div dir="ltr">Hi all,<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 10, 2018 at 5:07 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"><span class="">Am 10.03.2018 um 02:14 schrieb Udit agarwal:<br>
> Hi all, Hi Christian Mauderer, Hi Russel Haley,<br>
><br>
> I need some reviews/suggestions from the community regarding the idea of<br>
> Porting FreeBSD's SDIO driver to RTEMS via libbsd , building and testing<br>
> on Beaglebone Black BSP and then benchmarking it against our existing<br>
> SDHC driver.<br>
><br>
> Also, at this point, I find it a bit difficult to estimate the length of<br>
> this project, whether it's doable within GSoC timeframe or if it's<br>
> easier then my expectations then will it be a good idea to include other<br>
</span>> libbsd based projects like #3223 <<a href="https://devel.rtems.org/ticket/3223" rel="noreferrer" target="_blank">https://devel.rtems.org/<wbr>ticket/3223</a>> <br>
> or #3222 <<a href="https://devel.rtems.org/ticket/3222" rel="noreferrer" target="_blank">https://devel.rtems.org/<wbr>ticket/3222</a>> in my proposal to make it<br>
<span class="">> a bit fair and strong.<br>
><br>
> Regards,<br>
> Udit agarwal<br>
><br>
><br>
<br>
</span>Hello Udit,<br>
<br>
like I already said in another mail, it is a nice idea to have some<br>
performance numbers and a comparison between the two SD driver versions<br>
for the BBB in RTEMS and FreeBSD. There are currently only few numbers<br>
regarding how well FreeBSD drivers work on RTEMS compared to FreeBSD.<br>
<br>
Please note that the following list is only a first suggestion how I<br>
would approach this project. Some others might have other ideas and of<br>
course you can use another approach too.<br>
<br>
Some parts of the work are a little hard to estimate. So maybe adding an<br>
extended goal (like testing some other SDIO hardware beneath SD cards)<br>
could be added. But producing some good documentation should be the main<br>
goal of that project.<br>
<br>
Basically you will need the following points for that:<br>
<br>
-> A good solid test strategy for a performance test that works on<br>
FreeBSD and on RTEMS. Note that for that you maybe have to avoid using a<br>
file system. If used with the wrong options, the FAT file system on<br>
RTEMS is really a performance killer and would distort the comparison.<br>
<br></blockquote><div>Ok, i'll search for different benchmarks for that, keeping file system in mind. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-> A test setup for FreeBSD with the two different drivers. Most likely<br>
you can use the same system with two different kernel versions for that.<br>
Maybe you should search for the exact version where the driver has been<br>
added to avoid any other performance patches.<br>
<br>
-> On RTEMS the test setup might become a little more tricky: You need<br>
both driver versions. Ideally from the same commits like the ones you<br>
use for the FreeBSD tests. And that might become complicated:<br>
<br>
We had some problems in the past that the libbsd became quite<br>
unmaintainable because different parts had used different versions of<br>
FreeBSD as a base. For example that made it impossible to use USB<br>
Ethernet devices. About end of 2016 we resolved that. Now there is<br>
always only one version of FreeBSD used throughout the complete libbsd.<br>
<br>
So to get both driver versions, there are two possibilities:<br>
<br>
1. Ignore that rule and port a newer driver to the current version of<br>
libbsd. That is a bad idea because than we will again have problems with<br>
different versions. This kind of patch most likely couldn't be accepted<br>
in the official libbsd repository.<br>
<br>
2. Update libbsd to a more recent version and use that to test the new<br>
driver. Then (on a branch) port the old driver to this new version. I<br>
would think that this is a better idea but it involves one big problem:<br>
Updating the libbsd to a newer FreeBSD version. That needs some good<br>
knowledge about the libbsd structure and about FreeBSD.<br>
<br>
This point most likely needs the most discussion.<br>
<br></blockquote><div>Updating libbsd seems to be a bit 'more involved' task. SDIO subsystem was first added to FreeBSD<br></div><div>on 9, july, 2017 (<a href="https://github.com/freebsd/freebsd/search?p=1&q=sdio&type=Commits&utf8=%E2%9C%93">here</a>) , and our libbsd base is on FreeBSD head as on 2016-08-23 (<a href="https://lists.rtems.org/pipermail/devel/2016-November/016343.html">here</a>). So,<br></div><div>Incorporating SDIO driver needs updating libbsd to FreeBSD head on/after 9/07/2017.(right?)<br></div><div>@sebastian sir, maybe you would like to give some insight into this?<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Please note that this point is also vital for how much code from you<br>
will be visible after the project. Of course this kind of project will<br>
produce quite some documentation beneath the code which is great too.<br>
But if it is a important point for you that you can show a lot of code<br>
after GSoC, you might should think about whether that project is a good<br>
one for you.<br></blockquote><div>That's not really an issue, our main aim for GSoC is to learn, to get an intro of the<br></div><div>open source developing community while at the same time contributing something<br></div><div>valuable to the community. I initially liked this project for its vast implications not only on BBB <br></div><div>but on other BSPs also. If it seems complicated(Far beyond my scope), then it would be really fine<br></div><div>for me to take up other libbsd based projects :) just let me know! <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-> After you have that test setup, you should write some good<br>
documentation about what has been done and what results you have. That<br>
would be the main output produced by this GSoC project. It would be<br>
great if that is in the style of a short scientific paper or some kind<br>
of article that can be posted on the mailing list and maybe added to<br>
some documentation page on the RTEMS home page.<br>
<br>
Best regards<br>
<span class="HOEnZb"><font color="#888888"><br>
Christian Mauderer<br>
</font></span></blockquote></div><br></div><div class="gmail_extra">Best regards,<br></div><div class="gmail_extra">Udit agarwal<br></div></div></div>