GSoC'18 proposal - Porting SDIO driver and benchmarking

Gedare Bloom gedare at rtems.org
Tue Mar 20 16:26:03 UTC 2018


On Tue, Mar 20, 2018 at 11:56 AM, Udit agarwal <dev.madaari at gmail.com> wrote:
> Hi,
> We can't really merge the back-ported code with the current libbsd version
> to avoid version inconsistency.
> Thus, i am proposing to prepare all the necessary changes(patches), which
> can be applied once the libbsd receives it's next update.
>

Ah, OK. Thank you for clarifying this. Please make this be quite clear
in your proposal.

>
> On Tue, Mar 20, 2018 at 9:14 PM, Gedare Bloom <gedare at rtems.org> wrote:
>>
>> I have a question about the high-level goal of this project. Is it to
>> produce a back-ported version of the stack to our current libbsd, or
>> is to prepare the changes necessary to apply to libbsd when it gets
>> updated to a newer FreeBSD containing the sdio stack, or both?
>>
>> On Tue, Mar 20, 2018 at 11:41 AM, Udit agarwal <dev.madaari at gmail.com>
>> wrote:
>> > Hi,
>> >
>> > On Sun, Mar 18, 2018 at 8:48 PM, Christian Mauderer <list at c-mauderer.de>
>> > wrote:
>> >>
>> >> 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.
>> >>
>> > That's a really good idea! I have now included that in my proposal,
>> > please
>> > have a look.
>> >>
>> >>
>> >> 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.
>> >>
>> > Noted. I have corrected this. Moreover, i am studying several files
>> > changed/modified during
>> > the mmccam commit and as of now, i didn't  came across any such
>> > Non-RTEMS
>> > dependency
>> > that might affect systems performance. I have a query here, in
>> > RTEMS-libbsd
>> > cam directory, there are some files
>> > like cam.h and cam_ccb.h belonging to different FreeBSD head versions.
>> > Is it
>> > because, since there has been no change in the file, so its not updated?
>> >>
>> >>
>> >> 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.
>> >>
>> > I have corrected this. So, now the first phase, I'll be porting SDIO
>> > driver,
>> > and in the second and third phase, I'll focus on the benchmarking task.
>> > Hopefully, now we have ample time to fallback and search for another
>> > benchmarks in case the first one didn't work expectedly.
>> >>
>> >>
>> >> 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).
>> >>
>> > Done.
>> >>
>> >>
>> >> 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.
>> >>
>> > I came across several popular, multipurpose I/O benchmarks like IOZone
>> > and
>> > IOrate with compatible license(1,2). Since, these are FreeBSD compatible
>> > probably they will work. Still, I have added 'Searching and testing
>> > benchmarks on FreeBSD' as one of my goal.
>> >>
>> >> With kind regards
>> >>
>> >> Christian Mauderer
>> >
>> >
>> > Regards,
>> > Udit agarwal
>> >
>> > _______________________________________________
>> > devel mailing list
>> > devel at rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>
>


More information about the devel mailing list