Re: GSOC'18 contribution plan

2018-03-14 Thread Joel Sherrill
On Wed, Mar 14, 2018 at 10:59 AM, Hesham Almatary 
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  wrote:
> > On Tue, Mar 13, 2018 at 10:07 AM, Joel Sherrill  wrote:
> >>
> >>
> >> On Tue, Mar 13, 2018 at 8:46 AM, Vidushi Vashishth  >
> >> 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

Re: GSOC'18 contribution plan

2018-03-14 Thread Hesham Almatary
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  wrote:
> On Tue, Mar 13, 2018 at 10:07 AM, Joel Sherrill  wrote:
>>
>>
>> On Tue, Mar 13, 2018 at 8:46 AM, Vidushi Vashishth 
>> 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


Re: GSOC'18 contribution plan

2018-03-14 Thread Gedare Bloom
On Tue, Mar 13, 2018 at 10:07 AM, Joel Sherrill  wrote:
>
>
> On Tue, Mar 13, 2018 at 8:46 AM, Vidushi Vashishth 
> 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
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: GSOC'18 contribution plan

2018-03-13 Thread Joel Sherrill
On Tue, Mar 13, 2018 at 8:46 AM, Vidushi Vashishth 
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?


>
> 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
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel