Suggestions regarding GSoC project

[Christian Mauderer]

Am 10.03.2018 um 02:14 schrieb Udit agarwal:
> Hi all, Hi Christian Mauderer, Hi Russel Haley,
> 
> I need some reviews/suggestions from the community regarding the idea of
> Porting FreeBSD's SDIO driver to RTEMS via libbsd , building and testing
> on Beaglebone Black BSP and then benchmarking it against our existing
> SDHC driver.
> 
> Also, at this point, I find it a bit difficult to estimate the length of
> this project, whether it's doable within GSoC timeframe or if it's
> easier then my expectations then will it be a good idea to include other
> libbsd based projects like #3223 <https://devel.rtems.org/ticket/3223> 
> or #3222 <https://devel.rtems.org/ticket/3222> in my proposal to make it
> a bit fair and strong.
> 
> Regards,
> Udit agarwal
> 
> 

Hello Udit,

like I already said in another mail, it is a nice idea to have some
performance numbers and a comparison between the two SD driver versions
for the BBB in RTEMS and FreeBSD. There are currently only few numbers
regarding how well FreeBSD drivers work on RTEMS compared to FreeBSD.

Please note that the following list is only a first suggestion how I
would approach this project. Some others might have other ideas and of
course you can use another approach too.

Some parts of the work are a little hard to estimate. So maybe adding an
extended goal (like testing some other SDIO hardware beneath SD cards)
could be added. But producing some good documentation should be the main
goal of that project.

Basically you will need the following points for that:

-> A good solid test strategy for a performance test that works on
FreeBSD and on RTEMS. Note that for that you maybe have to avoid using a
file system. If used with the wrong options, the FAT file system on
RTEMS is really a performance killer and would distort the comparison.

-> A test setup for FreeBSD with the two different drivers. Most likely
you can use the same system with two different kernel versions for that.
Maybe you should search for the exact version where the driver has been
added to avoid any other performance patches.

-> On RTEMS the test setup might become a little more tricky: You need
both driver versions. Ideally from the same commits like the ones you
use for the FreeBSD tests. And that might become complicated:

We had some problems in the past that the libbsd became quite
unmaintainable because different parts had used different versions of
FreeBSD as a base. For example that made it impossible to use USB
Ethernet devices. About end of 2016 we resolved that. Now there is
always only one version of FreeBSD used throughout the complete libbsd.

So to get both driver versions, there are two possibilities:

1. Ignore that rule and port a newer driver to the current version of
libbsd. That is a bad idea because than we will again have problems with
different versions. This kind of patch most likely couldn't be accepted
in the official libbsd repository.

2. Update libbsd to a more recent version and use that to test the new
driver. Then (on a branch) port the old driver to this new version. I
would think that this is a better idea but it involves one big problem:
Updating the libbsd to a newer FreeBSD version. That needs some good
knowledge about the libbsd structure and about FreeBSD.

This point most likely needs the most discussion.

Please note that this point is also vital for how much code from you
will be visible after the project. Of course this kind of project will
produce quite some documentation beneath the code which is great too.
But if it is a important point for you that you can show a lot of code
after GSoC, you might should think about whether that project is a good
one for you.

-> After you have that test setup, you should write some good
documentation about what has been done and what results you have. That
would be the main output produced by this GSoC project. It would be
great if that is in the style of a short scientific paper or some kind
of article that can be posted on the mailing list and maybe added to
some documentation page on the RTEMS home page.

Best regards

Christian Mauderer