<div dir="ltr"><div><div>Hi,<br></div>We can't really merge the back-ported code with the current libbsd version to avoid version inconsistency.<br></div>Thus, i am proposing to prepare all the necessary changes(patches), which can be applied once the libbsd receives it's next update.<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 20, 2018 at 9:14 PM, Gedare Bloom <span dir="ltr"><<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I have a question about the high-level goal of this project. Is it to<br>
produce a back-ported version of the stack to our current libbsd, or<br>
is to prepare the changes necessary to apply to libbsd when it gets<br>
updated to a newer FreeBSD containing the sdio stack, or both?<br>
<div><div class="h5"><br>
On Tue, Mar 20, 2018 at 11:41 AM, Udit agarwal <<a href="mailto:dev.madaari@gmail.com">dev.madaari@gmail.com</a>> wrote:<br>
> Hi,<br>
><br>
> On Sun, Mar 18, 2018 at 8:48 PM, Christian Mauderer <<a href="mailto:list@c-mauderer.de">list@c-mauderer.de</a>><br>
> wrote:<br>
>><br>
>> Am 18.03.2018 um 14:22 schrieb Udit agarwal:<br>
>> > Hi all,<br>
>> > Here's the link to my proposal:<br>
>> ><br>
>> > <a href="https://docs.google.com/document/d/15Ut9FLAV3Y0Up1Qn02ys6KAb2QhtReF_P-wNR861NMo/edit?usp=sharing" rel="noreferrer" target="_blank">https://docs.google.com/<wbr>document/d/<wbr>15Ut9FLAV3Y0Up1Qn02ys6KAb2QhtR<wbr>eF_P-wNR861NMo/edit?usp=<wbr>sharing</a><br>
>> ><br>
>> > Please have a look, and comment where ever needed.<br>
>> > I tried my best to make time-line as realistic as possible. Please feel<br>
>> > free to comment in case of any unbalance or overlooked task.<br>
>> ><br>
>> > Regards,<br>
>> > Udit agarwal<br>
>> ><br>
>> ><br>
>><br>
>> Hello Udit,<br>
>><br>
>> some (not too well sorted) notes:<br>
>><br>
>> 1. One point I'm missing is the target that you produce a set of patches<br>
>> that can be easily merged as soon as the libbsd receives it's next<br>
>> update. Otherwise the only result from that project would be the<br>
>> comparison document.<br>
>><br>
> That's a really good idea! I have now included that in my proposal, please<br>
> have a look.<br>
>><br>
>><br>
>> 2. I'm not sure whether the point<br>
>><br>
>>   "Backport the SDIO driver residing within the mmccam stack to FreeBSD<br>
>> version being used by libbsd"<br>
>><br>
>> is a good idea. It sounds like you want to do the backport on FreeBSD.<br>
>> You most likely would have a lot of work with that without any really<br>
>> useful results. It would be better to analyse whether some other<br>
>> subsystems might have an influence on the performance measurement (which<br>
>> I would expect to be quite few) and then do the backport directly on<br>
>> RTEMS libbsd.<br>
>><br>
> Noted. I have corrected this. Moreover, i am studying several files<br>
> changed/modified during<br>
> the mmccam commit and as of now, i didn't  came across any such Non-RTEMS<br>
> dependency<br>
> that might affect systems performance. I have a query here, in RTEMS-libbsd<br>
> cam directory, there are some files<br>
> like cam.h and cam_ccb.h belonging to different FreeBSD head versions. Is it<br>
> because, since there has been no change in the file, so its not updated?<br>
>><br>
>><br>
>> 3. It seems that you have split up the test bench over all three phases.<br>
>> It might would be more efficient to search a test bench and get it<br>
>> running on FreeBSD as well as on RTEMS quite early. There should be no<br>
>> difference whether it runs on the old SD-card driver, the SDIO one or<br>
>> some USB stick. It should basically work with with any block device.<br>
>><br>
>> If you start to port it to RTEMS in phase 3 and then find out that it<br>
>> doesn't work like expected, you will have to restart with searching some<br>
>> other test bench. This would mean that you can throw away all results of<br>
>> the workbench that you collected in between.<br>
>><br>
> I have corrected this. So, now the first phase, I'll be porting SDIO driver,<br>
> and in the second and third phase, I'll focus on the benchmarking task.<br>
> Hopefully, now we have ample time to fallback and search for another<br>
> benchmarks in case the first one didn't work expectedly.<br>
>><br>
>><br>
>> 4. I'm not quite sure whether the amount of work would really fill all<br>
>> three phases. Maybe you should plan an extended goal. With that topic<br>
>> that could for example be a benchmark for some other drivers (like USB<br>
>> storage).<br>
>><br>
> Done.<br>
>><br>
>><br>
>> 5. Currently your results are a document and a set of patches that<br>
>> (hopefully) can be integrated into libbsd in the future. I think that if<br>
>> you find some good standard performance test for block devices, porting<br>
>> that could be another core result that can be integrated directly and<br>
>> not only after a libbsd upgrade.<br>
>><br>
> I came across several popular, multipurpose I/O benchmarks like IOZone and<br>
> IOrate with compatible license(1,2). Since, these are FreeBSD compatible<br>
> probably they will work. Still, I have added 'Searching and testing<br>
> benchmarks on FreeBSD' as one of my goal.<br>
>><br>
>> With kind regards<br>
>><br>
>> Christian Mauderer<br>
><br>
><br>
> Regards,<br>
> Udit agarwal<br>
><br>
</div></div>> ______________________________<wbr>_________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/devel</a><br>
</blockquote></div><br></div>