GSOC'18 contribution plan
heshamelmatary at gmail.com
Wed Mar 14 15:59:28 UTC 2018
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
On Thu, Mar 15, 2018 at 1:00 AM, Gedare Bloom <gedare at rtems.org> wrote:
> On Tue, Mar 13, 2018 at 10:07 AM, Joel Sherrill <joel at rtems.org> wrote:
>> On Tue, Mar 13, 2018 at 8:46 AM, Vidushi Vashishth <reachvidu at gmail.com>
>>> 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
>> 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
>> 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
>> 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...
>>> I intend to write my proposal in a week's time.
More information about the devel