On Wed, Mar 14, 2018 at 10:59 AM, Hesham Almatary <heshamelmat...@gmail.com> wrote:
> Rump kernels have the advantage of running "unmodified" NetBSD device > drivers and benchmarks (e.g. Redis, iPerf, etc) on top of the > underlying OS. AFAIK, it's well-designed to port on other OSes and the > requirements/syscalls for it are well documented/defined. > > That said, I'm not sure how this would overlap with the existing > RTEMS' libbsd project when it comes to the goals; others might > comment. > > heshamelmatary.blogspot.com/2015/02/thoughts-on- > supporting-rump-kernels-on.html I'm fine with it as a project. I just wanted to hear someone say something that gave it value. Just running the NetBSD filesystems and SATA driver would be a big win. It would be interesting to see this and compare the end result to rtems-libbsd. --joel > > > On Thu, Mar 15, 2018 at 1:00 AM, Gedare Bloom <ged...@rtems.org> wrote: > > On Tue, Mar 13, 2018 at 10:07 AM, Joel Sherrill <j...@rtems.org> wrote: > >> > >> > >> On Tue, Mar 13, 2018 at 8:46 AM, Vidushi Vashishth <reachv...@gmail.com > > > >> wrote: > >>> > >>> Hello! > >>> > >>> I am Vidushi Vashishth from Netaji Subhas Institute of Technology, > Delhi > >>> and I intend to participate in the selection procedure for GSOC'18. I > have > >>> already submitted the Hello world patch. The past couple of days I > have been > >>> going through the open projects and I am interested in the ones below: > >> > >> > >> Awesome! Make sure you are on the list here. > >>> > >>> > >>> 1) Run time tracing > >>> For this project I have been reading about the Common Trace Format > >>> Integration, Trace Buffering, RTEMS trace linker's working which > utilises > >>> INI configuration files. I have been following the ticket #3028. I am > >>> currently working on the tasks present on the ticket's description. It > would > >>> be helpful if the community could point out to any other relevant > issues > >>> which I could work on to get a better idea about this project. I would > get > >>> back when I find one myself. As suggested on the mailing list, I would > also > >>> like to investigate the TCF project to see if a combination of both of > these > >>> can be undertaken in one summer. Let me know if this is too optimistic. > >> > >> > >> As I mentioned on another thread this morning, CTF and TCF are IMO very > >> important things > >> for RTEMS to support. Sebastian was commenting how the tracing would > help > >> him. > >> If I had to assign a priority to the two, I guess I would put CTF first > >> because it fills a gap. > >> TCF is also important but we do have debugging now but TCF might offer > some > >> unique > >> capability we don't have. > >> > >>> > >>> > >>> 2) Rump Kernels > >>> The project's description was a little open ended but garnered my > >>> interest. It would require a little more research from my end to come > up > >>> with ideas myself. I would do that if time permits. > >> > >> > >> Given the current status of libbsd, I am not sure what the goal of it > would > >> be. I think > >> originally it was proposed as an alternative way to get many BSD > >> capabilities onto > >> RTEMS. > >> > >> Can someone comment? > >> > > > > Rump kernels may still have utility for adopting portable subsystems > > from NetBSD code base without a major import hassle. It also could be > > complementary to libbsd perhaps. Hesham did some initial research in > > this direction before being distracted by other pursuits, so he might > > have some more insight. He wrote a blog post about it before... > > > > Gedare > > > >>> > >>> > >>> I intend to write my proposal in a week's time. > >>> > >>> References: > >>> https://devel.rtems.org/ticket/3028 > >>> https://devel.rtems.org/wiki/Developer/Projects/Open/RumpKernels > >>> > >>> Best, > >>> Vidushi > >>> > >> > > > > -- > Hesham >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel