GSoC'18 proposal - Porting SDIO driver and benchmarking

[Gedare Bloom]

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