GSOC'18 contribution plan

[Joel Sherrill]

On Wed, Mar 14, 2018 at 10:59 AM, Hesham Almatary <heshamelmatary at 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 <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
> >
> >> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180314/d67c3f4f/attachment-0002.html>