Re: GSoC 2018 (x86_64, pc386, SMP improvements, rump kernels)

2018-03-13 Thread Amaan Cheval 
I like the sound of that! One quick question.

> ...to get it running on qemu. Real HW would be a sanity check.

What kind of real hardware would I need? I do have an x86 64-bit processor
as my primary computer, and likely one on spare / abandoned devices too
(though I'll need to confirm). Is there anything specific that you foresee
me needing to check to confirm they'll be good enough for the purposes of
this project (besides UEFI)?

I also vaguely remember OAR hosting a lab with a bunch of development
boards; does the lab have x86_64 hardware?

On Tue, Mar 13, 2018 at 2:04 AM Joel Sherrill  wrote:



> On Mon, Mar 12, 2018 at 3:20 PM, Gedare Bloom  wrote:

>> On Mon, Mar 12, 2018 at 12:41 PM, Amaan Cheval 
wrote:
>> > On Mon, Mar 12, 2018 at 9:53 PM Gedare Bloom  wrote:
>> >
>> >> On Mon, Mar 12, 2018 at 3:01 AM, Sebastian Huber
>> >>  wrote:
>> >> > On 10/03/18 18:02, Amaan Cheval wrote:
>> >> >>
>> >> >> - Improve RTEMS SMP[3]
>> >> >>
>> >> >> What kinds of improvements to SMP are we considering?
>> >> >
>> >> >
>> >> > The SMP support is quite complete now. In general, an independent
>> > review is
>> >> > required, but this is probably not a GSoC project. Some areas in the
>> >> > implementation are a bit too complex (e.g. thread lock) and should
be
>> >> > simplified, however, I guess this is a very difficult task.
>> >> >
>> >> > A formal specification using TLA+ for the OMIP and MrsP locking
>> > protocols
>> >> > would be nice.
>> >> >
>> >> > https://en.wikipedia.org/wiki/TLA%2B
>> >> >
>> >> > A proper strong APA scheduler:
>> >> >
>> >> > https://devel.rtems.org/ticket/2510
>> >> >
>> >> > I am not sure if there is a real application demand for this.
>> >> >
>> >
>> >> I would be supportive of formal specification or strong APA projects
>> >> despite user demand.
>> >
>> > That's good to know! I'll look into it! :)
>> >
>> >
>> >> >> As noted earlier, SMP
>> >> >> support on i386 is lagging. Is there any interest in bringing that
up
>> > to
>> >> >> par with the other architectures?
>> >> >
>> >> >
>> >> > I think this makes only sense for a x86_64 BSP.
>> >> >
>> >
>> >> There is a need for a modernized framework for x86 and x86_64. Both
>> >> projects are relevant and important.
>> >
>> > That's good to know. I haven't been able to quite tease the 2 projects
>> > apart; for eg. it seems the x86_64 BSP would also be based on
non-legacy
>> > hardware (UEFI vs. BIOS?), so it would be tied to improving the
existing
>> > PC386 code as well.
>> >
>> > I think my main proposal will be along these lines; figuring out the
>> > essentials for the x86_64 BSP, and modernizing the existing x86 as I
can at
>> > the same time.
>> >
>> > How does that sound?
>> >

>> I think that should be appropriate. You should be able to demonstrate
>> progress on the new BSP then, while you contribute code to the old
>> one.


> When Chris and I have discussed this in the past, we have tossed around
> the idea of a new port -- x86_64,. a true 64-bit port. It would have a new
> BSP that would not depend on legacy hardware and would boot using UEFI.

> To pace this out so it is achievable in a summer, the first steps would
> focus on the port proper and do the minimum required of a BSP to get
> it running on qemu. Real HW would be a sanity check. Focus on a port
> and minimum BSP (initialization, console, clock tick).

> Chris has suggested that the BSP could use whatever it needed from
> FreeBSD, such as UEFI support.

> Key.. new port.. new BSP.. without the legacy baggage of 32-bit and old
HW.
> More work but a much better result in the long run.



>> > Since I'm pretty keen on RTEMS, I think I'll have a 2nd proposal too,
which
>> > I'll decide and discuss with you guys soon, hopefully! (Perhaps the
tracing
>> > or the APA scheduling projects).
>> >

>> That's fine.  I don't think APA by itself is enough for the summer.

>> >
>> >> > From an application developer point of view a ready to use tracing
of
>> > thread
>> >> > context switches and interrupts would be nice. Some kind of data
>> > provider
>> >> > for the lttng-relayd (LTTng 2 relay daemon)
>> >> >
>> >> > https://lttng.org/docs/v2.10/#doc-lttng-relayd
>> >> >
>> >> > Which can be used by
>> >> >
>> >> > https://projects.eclipse.org/projects/tools.tracecompass
>> >> >
>> >
>> >> Joel has been looking at the trace compass. We also have other tracing
>> >> projects (barectf integration) that would be relevant to investigate
>> >> along those same lines.
>> >
>> >> > --
>> >> > Sebastian Huber, embedded brains GmbH
>> >> >
>> >> > Address : Dornierstr. 4, D-82178 Puchheim, Germany
>> >> > Phone   : +49 89 189 47 41-16
>> >> > Fax : +49 89 189 47 41-09
>> >> > E-Mail  : sebastian.hu...@embedded-brains.de
>> >> > PGP : Public key available on request.
>> >> >
>> >> > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des
EHUG.
>> >> >

Re: GSoC 2018 (x86_64, pc386, SMP improvements, rump kernels)

2018-03-13 Thread Joel Sherrill 
On Mar 13, 2018 1:36 AM, "Sebastian Huber" <
sebastian.hu...@embedded-brains.de> wrote:

On 12/03/18 21:20, Gedare Bloom wrote:

> Since I'm pretty keen on RTEMS, I think I'll have a 2nd proposal too, which
>> I'll decide and discuss with you guys soon, hopefully! (Perhaps the
>> tracing
>> or the APA scheduling projects).
>>
>> That's fine.  I don't think APA by itself is enough for the summer.
>
>
The strong APA scheduler was a GSoC project last year. Unfortunately the
student got ill and could not really work on it.

I think a ready to use tracing framework with good support from standard
tools would be quite nice for RTEMS application development. I have some
network stack performance issues which are probably more easy to track down
with such a tool ;-)


The  Common Trace Format (CTF) project is the one I steering students to
for this use case. It is what integrates into Eclipse and lets you use the
Linux Trace Toolkit (LTTNG). That tool visualizes trace logs, can do it
live or from logs, and has built-in capability to detect some behavioral
errors based on logged event patterns.

The cousin of this is the TCF project for remote debugging and target
interaction. Also used by Eclipse.

As far as I can tell, those are the two pieces required to give us a really
nice and complete Eclipse environment.


-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchhe
im,
Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2018 (x86_64, pc386, SMP improvements, rump kernels)

2018-03-12 Thread Joel Sherrill 
On Mon, Mar 12, 2018 at 3:20 PM, Gedare Bloom  wrote:

> On Mon, Mar 12, 2018 at 12:41 PM, Amaan Cheval 
> wrote:
> > On Mon, Mar 12, 2018 at 9:53 PM Gedare Bloom  wrote:
> >
> >> On Mon, Mar 12, 2018 at 3:01 AM, Sebastian Huber
> >>  wrote:
> >> > On 10/03/18 18:02, Amaan Cheval wrote:
> >> >>
> >> >> - Improve RTEMS SMP[3]
> >> >>
> >> >> What kinds of improvements to SMP are we considering?
> >> >
> >> >
> >> > The SMP support is quite complete now. In general, an independent
> > review is
> >> > required, but this is probably not a GSoC project. Some areas in the
> >> > implementation are a bit too complex (e.g. thread lock) and should be
> >> > simplified, however, I guess this is a very difficult task.
> >> >
> >> > A formal specification using TLA+ for the OMIP and MrsP locking
> > protocols
> >> > would be nice.
> >> >
> >> > https://en.wikipedia.org/wiki/TLA%2B
> >> >
> >> > A proper strong APA scheduler:
> >> >
> >> > https://devel.rtems.org/ticket/2510
> >> >
> >> > I am not sure if there is a real application demand for this.
> >> >
> >
> >> I would be supportive of formal specification or strong APA projects
> >> despite user demand.
> >
> > That's good to know! I'll look into it! :)
> >
> >
> >> >> As noted earlier, SMP
> >> >> support on i386 is lagging. Is there any interest in bringing that up
> > to
> >> >> par with the other architectures?
> >> >
> >> >
> >> > I think this makes only sense for a x86_64 BSP.
> >> >
> >
> >> There is a need for a modernized framework for x86 and x86_64. Both
> >> projects are relevant and important.
> >
> > That's good to know. I haven't been able to quite tease the 2 projects
> > apart; for eg. it seems the x86_64 BSP would also be based on non-legacy
> > hardware (UEFI vs. BIOS?), so it would be tied to improving the existing
> > PC386 code as well.
> >
> > I think my main proposal will be along these lines; figuring out the
> > essentials for the x86_64 BSP, and modernizing the existing x86 as I can
> at
> > the same time.
> >
> > How does that sound?
> >
>
> I think that should be appropriate. You should be able to demonstrate
> progress on the new BSP then, while you contribute code to the old
> one.
>

When Chris and I have discussed this in the past, we have tossed around
the idea of a new port -- x86_64,. a true 64-bit port. It would have a new
BSP that would not depend on legacy hardware and would boot using UEFI.

To pace this out so it is achievable in a summer, the first steps would
focus on the port proper and do the minimum required of a BSP to get
it running on qemu. Real HW would be a sanity check. Focus on a port
and minimum BSP (initialization, console, clock tick).

Chris has suggested that the BSP could use whatever it needed from
FreeBSD, such as UEFI support.

Key.. new port.. new BSP.. without the legacy baggage of 32-bit and old HW.
More work but a much better result in the long run.


>
> > Since I'm pretty keen on RTEMS, I think I'll have a 2nd proposal too,
> which
> > I'll decide and discuss with you guys soon, hopefully! (Perhaps the
> tracing
> > or the APA scheduling projects).
> >
>
> That's fine.  I don't think APA by itself is enough for the summer.
>
> >
> >> > From an application developer point of view a ready to use tracing of
> > thread
> >> > context switches and interrupts would be nice. Some kind of data
> > provider
> >> > for the lttng-relayd (LTTng 2 relay daemon)
> >> >
> >> > https://lttng.org/docs/v2.10/#doc-lttng-relayd
> >> >
> >> > Which can be used by
> >> >
> >> > https://projects.eclipse.org/projects/tools.tracecompass
> >> >
> >
> >> Joel has been looking at the trace compass. We also have other tracing
> >> projects (barectf integration) that would be relevant to investigate
> >> along those same lines.
> >
> >> > --
> >> > Sebastian Huber, embedded brains GmbH
> >> >
> >> > Address : Dornierstr. 4, D-82178 Puchheim, Germany
> >> > Phone   : +49 89 189 47 41-16
> >> > Fax : +49 89 189 47 41-09
> >> > E-Mail  : sebastian.hu...@embedded-brains.de
> >> > PGP : Public key available on request.
> >> >
> >> > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> >> >
> >> >
> >> > ___
> >> > devel mailing list
> >> > devel@rtems.org
> >> > http://lists.rtems.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2018 (x86_64, pc386, SMP improvements, rump kernels)

2018-03-12 Thread Gedare Bloom 
On Mon, Mar 12, 2018 at 12:41 PM, Amaan Cheval  wrote:
> On Mon, Mar 12, 2018 at 9:53 PM Gedare Bloom  wrote:
>
>> On Mon, Mar 12, 2018 at 3:01 AM, Sebastian Huber
>>  wrote:
>> > On 10/03/18 18:02, Amaan Cheval wrote:
>> >>
>> >> - Improve RTEMS SMP[3]
>> >>
>> >> What kinds of improvements to SMP are we considering?
>> >
>> >
>> > The SMP support is quite complete now. In general, an independent
> review is
>> > required, but this is probably not a GSoC project. Some areas in the
>> > implementation are a bit too complex (e.g. thread lock) and should be
>> > simplified, however, I guess this is a very difficult task.
>> >
>> > A formal specification using TLA+ for the OMIP and MrsP locking
> protocols
>> > would be nice.
>> >
>> > https://en.wikipedia.org/wiki/TLA%2B
>> >
>> > A proper strong APA scheduler:
>> >
>> > https://devel.rtems.org/ticket/2510
>> >
>> > I am not sure if there is a real application demand for this.
>> >
>
>> I would be supportive of formal specification or strong APA projects
>> despite user demand.
>
> That's good to know! I'll look into it! :)
>
>
>> >> As noted earlier, SMP
>> >> support on i386 is lagging. Is there any interest in bringing that up
> to
>> >> par with the other architectures?
>> >
>> >
>> > I think this makes only sense for a x86_64 BSP.
>> >
>
>> There is a need for a modernized framework for x86 and x86_64. Both
>> projects are relevant and important.
>
> That's good to know. I haven't been able to quite tease the 2 projects
> apart; for eg. it seems the x86_64 BSP would also be based on non-legacy
> hardware (UEFI vs. BIOS?), so it would be tied to improving the existing
> PC386 code as well.
>
> I think my main proposal will be along these lines; figuring out the
> essentials for the x86_64 BSP, and modernizing the existing x86 as I can at
> the same time.
>
> How does that sound?
>

I think that should be appropriate. You should be able to demonstrate
progress on the new BSP then, while you contribute code to the old
one.

> Since I'm pretty keen on RTEMS, I think I'll have a 2nd proposal too, which
> I'll decide and discuss with you guys soon, hopefully! (Perhaps the tracing
> or the APA scheduling projects).
>

That's fine.  I don't think APA by itself is enough for the summer.

>
>> > From an application developer point of view a ready to use tracing of
> thread
>> > context switches and interrupts would be nice. Some kind of data
> provider
>> > for the lttng-relayd (LTTng 2 relay daemon)
>> >
>> > https://lttng.org/docs/v2.10/#doc-lttng-relayd
>> >
>> > Which can be used by
>> >
>> > https://projects.eclipse.org/projects/tools.tracecompass
>> >
>
>> Joel has been looking at the trace compass. We also have other tracing
>> projects (barectf integration) that would be relevant to investigate
>> along those same lines.
>
>> > --
>> > Sebastian Huber, embedded brains GmbH
>> >
>> > Address : Dornierstr. 4, D-82178 Puchheim, Germany
>> > Phone   : +49 89 189 47 41-16
>> > Fax : +49 89 189 47 41-09
>> > E-Mail  : sebastian.hu...@embedded-brains.de
>> > PGP : Public key available on request.
>> >
>> > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>> >
>> >
>> > ___
>> > devel mailing list
>> > devel@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2018 (x86_64, pc386, SMP improvements, rump kernels)

2018-03-12 Thread Amaan Cheval 
On Mon, Mar 12, 2018 at 9:53 PM Gedare Bloom  wrote:

> On Mon, Mar 12, 2018 at 3:01 AM, Sebastian Huber
>  wrote:
> > On 10/03/18 18:02, Amaan Cheval wrote:
> >>
> >> - Improve RTEMS SMP[3]
> >>
> >> What kinds of improvements to SMP are we considering?
> >
> >
> > The SMP support is quite complete now. In general, an independent
review is
> > required, but this is probably not a GSoC project. Some areas in the
> > implementation are a bit too complex (e.g. thread lock) and should be
> > simplified, however, I guess this is a very difficult task.
> >
> > A formal specification using TLA+ for the OMIP and MrsP locking
protocols
> > would be nice.
> >
> > https://en.wikipedia.org/wiki/TLA%2B
> >
> > A proper strong APA scheduler:
> >
> > https://devel.rtems.org/ticket/2510
> >
> > I am not sure if there is a real application demand for this.
> >

> I would be supportive of formal specification or strong APA projects
> despite user demand.

That's good to know! I'll look into it! :)


> >> As noted earlier, SMP
> >> support on i386 is lagging. Is there any interest in bringing that up
to
> >> par with the other architectures?
> >
> >
> > I think this makes only sense for a x86_64 BSP.
> >

> There is a need for a modernized framework for x86 and x86_64. Both
> projects are relevant and important.

That's good to know. I haven't been able to quite tease the 2 projects
apart; for eg. it seems the x86_64 BSP would also be based on non-legacy
hardware (UEFI vs. BIOS?), so it would be tied to improving the existing
PC386 code as well.

I think my main proposal will be along these lines; figuring out the
essentials for the x86_64 BSP, and modernizing the existing x86 as I can at
the same time.

How does that sound?

Since I'm pretty keen on RTEMS, I think I'll have a 2nd proposal too, which
I'll decide and discuss with you guys soon, hopefully! (Perhaps the tracing
or the APA scheduling projects).


> > From an application developer point of view a ready to use tracing of
thread
> > context switches and interrupts would be nice. Some kind of data
provider
> > for the lttng-relayd (LTTng 2 relay daemon)
> >
> > https://lttng.org/docs/v2.10/#doc-lttng-relayd
> >
> > Which can be used by
> >
> > https://projects.eclipse.org/projects/tools.tracecompass
> >

> Joel has been looking at the trace compass. We also have other tracing
> projects (barectf integration) that would be relevant to investigate
> along those same lines.

> > --
> > Sebastian Huber, embedded brains GmbH
> >
> > Address : Dornierstr. 4, D-82178 Puchheim, Germany
> > Phone   : +49 89 189 47 41-16
> > Fax : +49 89 189 47 41-09
> > E-Mail  : sebastian.hu...@embedded-brains.de
> > PGP : Public key available on request.
> >
> > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> >
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2018 (x86_64, pc386, SMP improvements, rump kernels)

2018-03-12 Thread Gedare Bloom 
On Mon, Mar 12, 2018 at 3:01 AM, Sebastian Huber
 wrote:
> On 10/03/18 18:02, Amaan Cheval wrote:
>>
>> - Improve RTEMS SMP[3]
>>
>> What kinds of improvements to SMP are we considering?
>
>
> The SMP support is quite complete now. In general, an independent review is
> required, but this is probably not a GSoC project. Some areas in the
> implementation are a bit too complex (e.g. thread lock) and should be
> simplified, however, I guess this is a very difficult task.
>
> A formal specification using TLA+ for the OMIP and MrsP locking protocols
> would be nice.
>
> https://en.wikipedia.org/wiki/TLA%2B
>
> A proper strong APA scheduler:
>
> https://devel.rtems.org/ticket/2510
>
> I am not sure if there is a real application demand for this.
>

I would be supportive of formal specification or strong APA projects
despite user demand.

>> As noted earlier, SMP
>> support on i386 is lagging. Is there any interest in bringing that up to
>> par with the other architectures?
>
>
> I think this makes only sense for a x86_64 BSP.
>

There is a need for a modernized framework for x86 and x86_64. Both
projects are relevant and important. I tend to agree that the SMP
support for 32-bit x86 is a low priority.

> From an application developer point of view a ready to use tracing of thread
> context switches and interrupts would be nice. Some kind of data provider
> for the lttng-relayd (LTTng 2 relay daemon)
>
> https://lttng.org/docs/v2.10/#doc-lttng-relayd
>
> Which can be used by
>
> https://projects.eclipse.org/projects/tools.tracecompass
>

Joel has been looking at the trace compass. We also have other tracing
projects (barectf integration) that would be relevant to investigate
along those same lines.

> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2018 (x86_64, pc386, SMP improvements, rump kernels)

2018-03-12 Thread Sebastian Huber 

On 10/03/18 18:02, Amaan Cheval wrote:

- Improve RTEMS SMP[3]

What kinds of improvements to SMP are we considering?


The SMP support is quite complete now. In general, an independent review 
is required, but this is probably not a GSoC project. Some areas in the 
implementation are a bit too complex (e.g. thread lock) and should be 
simplified, however, I guess this is a very difficult task.


A formal specification using TLA+ for the OMIP and MrsP locking 
protocols would be nice.


https://en.wikipedia.org/wiki/TLA%2B

A proper strong APA scheduler:

https://devel.rtems.org/ticket/2510

I am not sure if there is a real application demand for this.


As noted earlier, SMP
support on i386 is lagging. Is there any interest in bringing that up to
par with the other architectures?


I think this makes only sense for a x86_64 BSP.

From an application developer point of view a ready to use tracing of 
thread context switches and interrupts would be nice. Some kind of data 
provider for the lttng-relayd (LTTng 2 relay daemon)


https://lttng.org/docs/v2.10/#doc-lttng-relayd

Which can be used by

https://projects.eclipse.org/projects/tools.tracecompass

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

GSoC 2018 (x86_64, pc386, SMP improvements, rump kernels)

2018-03-10 Thread Amaan Cheval 
Hi!

I've introduced myself in the past, but just to reiterate; I'm a final year
Bachelor's in Engineering student at Thakur College of Engineering, in
Mumbai. I work part-time on an Intel x86 emulator, written primarily in C
and JavaScript (that's right :P) - we also have a JIT compiler for
x86->WebAssembly. I've had an interest in reverse engineering, compiler
theory, and operating systems, and Linux specifically, for quite a while
now.

Anyway, given that the time to work on our GSoC proposals is nigh, I
figured I'd solicit more information for the projects that I'm interested
in:

- x86_64 BSP[1]

This seems like a fairly large undertaking, with potential overlaps with
the next project (pc386 improvement). Does anyone know what subset of the
listed items may be considered the "core", for completion within the GSoC
period? Is there anything I can look into right now to (1) better gauge the
kind of work involved in this project and (2) to better estimate how the
work will need to be split up in terms of time?

I'm looking into the BSP porting guide, and just the source code for BSPs
and no_cpu in specific to get a better feel for how RTEMS structures these
things at the moment.

- Improve PC386 BSP[2]

Seems to contain a fair bit of information already - I'm hoping to look
into #2183 as time permits to figure out better what some of the work on
this project will be like. Are there any other potential next steps I
should consider?

- Improve RTEMS SMP[3]

What kinds of improvements to SMP are we considering? As noted earlier, SMP
support on i386 is lagging. Is there any interest in bringing that up to
par with the other architectures?

- Rump kernel hypercall interface[4]

Given that this project hasn't been converted to a ticket, I imagine that
this is lower in priority. Let me know if that's not the case, though?

---

I'm hoping to get a proposal or two prepared within the coming week to give
the community a fair amount of time to critique it and propose changes /
additions to it before the deadline. I'd like to figure out what's
realistic to propose, and what's required most by RTEMS, so any information
would be useful.

Thanks!

[1] https://devel.rtems.org/ticket/2898
[2] https://devel.rtems.org/ticket/2900
[3] https://devel.rtems.org/wiki/Developer/Projects/Open/ImproveSMP
[4] https://devel.rtems.org/wiki/Developer/Projects/Open/RumpKernels
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel