Suggestions regarding GSoC project

[Udit agarwal]

Hi all,

On Sat, Mar 10, 2018 at 5:07 PM, Christian Mauderer <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>
> > 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.
>
> Ok, i'll search for different benchmarks for that, keeping file system in
mind.

> -> 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?

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. 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!

>
> -> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180310/11ab2b2f/attachment-0002.html>