Suggestions regarding GSoC project

Sat Mar 10 19:19:03 UTC 2018

Am 10.03.2018 um 19:08 schrieb Udit agarwal:
> Hi all,
> 
> On Sat, Mar 10, 2018 at 5:07 PM, Christian Mauderer <list at c-mauderer.de
> <mailto:list at c-mauderer.de>> wrote:
> 
>     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
>     <https://devel.rtems.org/ticket/3223>> 
>     > or #3222 <https://devel.rtems.org/ticket/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.
> 
> Ok, i'll search for different benchmarks for that, keeping file system
> in mind.

I think most likely you will need something that works on a raw block
device with different block sizes. But searching that test would be one
part of your work. So put it as one point on your time line.

> 
>     -> 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.
> 
> Updating libbsd seems to be a bit 'more involved' task. SDIO subsystem
> was first added to FreeBSD
> on 9, july, 2017 (here
> <https://github.com/freebsd/freebsd/search?p=1&q=sdio&type=Commits&utf8=%E2%9C%93>)
> , and our libbsd base is on FreeBSD head as on 2016-08-23 (here
> <https://lists.rtems.org/pipermail/devel/2016-November/016343.html>). So,
> Incorporating SDIO driver needs updating libbsd to FreeBSD head on/after
> 9/07/2017.(right?)
> @sebastian sir, maybe you would like to give some insight into this?

Sebastian is most likely the right one for the update. He did the last ones.

If you want to do this yourself: Plan enough time and a lot of questions
on the mailing list or via IRC ;-)

> 
>     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.
> 
> That's not really an issue, our main aim for GSoC is to learn, to get an
> intro of the
> open source developing community while at the same time contributing
> something
> valuable to the community.

Good. I only wanted that you are aware of that. Like I said: Having some
real performance tests comparing with other implementations are great
for an open source project too.

> I initially liked this project for its vast
> implications not only on BBB
> but on other BSPs also. If it seems complicated(Far beyond my scope),
> then it would be really fine
> for me to take up other libbsd based projects :) just let me know!

I don't think that's beyond your scope. From what I've seen till now, it
seems that you have no problems when digging into some code (for example
the fdt and U-Boot). So I think that you can manage that. The only part
that would get tricky is the libbsd update. Theoretically it is also
possible to backport the driver to the current libbsd and do the
comparison with that. But like I said: These kind of patches would most
likely not be added to the libbsd because they would introduce a version
inconsistency.

Regarding libbsd projects: The two projects on the Open Projects list
regarding WiFi support are not BBB specific. On contrary: They are not
hardware specific at all. The BBB is only a quite well supported and
easily available platform for the development. Therefore I suggested it
in the tickets. But basically any board with a USB controller supported
in libbsd could use a WiFi-Dongle with that.

> 
>     -> 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
> 
> 
> Best regards,
> Udit agarwal
> 
> 
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> 