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