GSoC'18 proposal - Porting SDIO driver and benchmarking
Christian Mauderer
list at c-mauderer.de
Sun Mar 18 15:18:57 UTC 2018
Am 18.03.2018 um 14:22 schrieb Udit agarwal:
> Hi all,
> Here's the link to my proposal:
> https://docs.google.com/document/d/15Ut9FLAV3Y0Up1Qn02ys6KAb2QhtReF_P-wNR861NMo/edit?usp=sharing
>
> Please have a look, and comment where ever needed.
> I tried my best to make time-line as realistic as possible. Please feel
> free to comment in case of any unbalance or overlooked task.
>
> Regards,
> Udit agarwal
>
>
Hello Udit,
some (not too well sorted) notes:
1. One point I'm missing is the target that you produce a set of patches
that can be easily merged as soon as the libbsd receives it's next
update. Otherwise the only result from that project would be the
comparison document.
2. I'm not sure whether the point
"Backport the SDIO driver residing within the mmccam stack to FreeBSD
version being used by libbsd"
is a good idea. It sounds like you want to do the backport on FreeBSD.
You most likely would have a lot of work with that without any really
useful results. It would be better to analyse whether some other
subsystems might have an influence on the performance measurement (which
I would expect to be quite few) and then do the backport directly on
RTEMS libbsd.
3. It seems that you have split up the test bench over all three phases.
It might would be more efficient to search a test bench and get it
running on FreeBSD as well as on RTEMS quite early. There should be no
difference whether it runs on the old SD-card driver, the SDIO one or
some USB stick. It should basically work with with any block device.
If you start to port it to RTEMS in phase 3 and then find out that it
doesn't work like expected, you will have to restart with searching some
other test bench. This would mean that you can throw away all results of
the workbench that you collected in between.
4. I'm not quite sure whether the amount of work would really fill all
three phases. Maybe you should plan an extended goal. With that topic
that could for example be a benchmark for some other drivers (like USB
storage).
5. Currently your results are a document and a set of patches that
(hopefully) can be integrated into libbsd in the future. I think that if
you find some good standard performance test for block devices, porting
that could be another core result that can be integrated directly and
not only after a libbsd upgrade.
With kind regards
Christian Mauderer
More information about the devel
mailing list