On Tue, Mar 20, 2018 at 11:56 AM, Udit agarwal <dev.mada...@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 <ged...@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.mada...@gmail.com> >> wrote: >> > Hi, >> > >> > On Sun, Mar 18, 2018 at 8:48 PM, Christian Mauderer <l...@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@rtems.org >> > http://lists.rtems.org/mailman/listinfo/devel > > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel