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 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
