Re: GSoC 2018 project announced

2018-04-24 Thread Vijay Kumar Banerjee 
Yes I have received the mail

Thank you!


On Tue, 24 Apr 2018, 20:15 Gedare Bloom,  wrote:

> All students should have received an email from me today about how to
> proceed.
>
> On Mon, Apr 23, 2018 at 5:43 PM, Vijay Kumar Banerjee
>  wrote:
> > Hello mentors,
> >
> > Thank you for letting me have this wonderful opportunity to work with
> RTEMS
> > under the GSoC 2018 program!!
> >
> > I would like to ask about the instructions regarding the program that I
> need
> > to follow to get started properly, (like adding the project to the GSoC
> > tracking page )
> >
> >
> > -- vijay
> >
> > ___
> > 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 project announced

2018-04-24 Thread Gedare Bloom 
All students should have received an email from me today about how to proceed.

On Mon, Apr 23, 2018 at 5:43 PM, Vijay Kumar Banerjee
 wrote:
> Hello mentors,
>
> Thank you for letting me have this wonderful opportunity to work with RTEMS
> under the GSoC 2018 program!!
>
> I would like to ask about the instructions regarding the program that I need
> to follow to get started properly, (like adding the project to the GSoC
> tracking page )
>
>
> -- vijay
>
> ___
> 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

2018-03-16 Thread Joel Sherrill 
Check out the csv file in rtems-docs/posix-compliance. Chris and I put
together a new POSIX Compliance Guide. It is on docs.rtems.org.

Check out the guide and the new csv. Up to date and lots of POSIX profiles.
:)

Even has guidance on finding methods to implement. Between that and the
ticket, should be a good start.

On Mar 16, 2018 1:58 PM, "Aditya Upadhyay"  wrote:

> Hi Joel,
>
> I am sharing one spreadsheet to Salil what you had shared with me last
> year. It will also help him to identify the works that need to be included
> as a
> part of GSoC-2018.
>
>
> On Sat, Mar 17, 2018 at 12:08 AM, Joel Sherrill  wrote:
> > Are you interested in the POSIX Compliance project?
> >
> > If so, you really need to get your proposal together and submitted. Then
> we
> > can worry about doing the work proposed. With no proposal, you can't
> > get accepted.
> >
> > https://devel.rtems.org/ticket/2966 is the POSIX Compliance ticket. It
> > has sub-tickets for individual tasks that has been identified so far.
> >
> Can you please see the ticket: https://devel.rtems.org/ticket/2968
> It was a part of GSoC-2017. I have already ported Inttypes methods to
> newlib.
> Could you please close this sub-ticket?
>
> Thanks & Regards,
> Aditya Upadhyay
>
> > --joel
> >
> > On Fri, Mar 16, 2018 at 1:25 PM, Salil Sirotia 
> > wrote:
> >>
> >> Hello Developers,
> >>
> >> At this point of time, I have built the newlib for SPARC BSP and
> >> subscribed myself for newlib mailing list.Could you please suggest me
> any
> >> library or some of the functions that is needed to port to newlib? Any
> >> response from your side would be
> >> greatly appreciated.
> >>
> >> That would be great and easy start for me towards GSoC-2018.
> >>
> >> Thanks & regards,
> >> Salil Sirotia,
> >> Mtech,CSE-IS(Final Year),
> >> IIT(ISM),Dhanbad
> >>
> >> ___
> >> 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

2018-03-16 Thread Joel Sherrill 
Are you interested in the POSIX Compliance project?

If so, you really need to get your proposal together and submitted. Then we
can worry about doing the work proposed. With no proposal, you can't
get accepted.

https://devel.rtems.org/ticket/2966 is the POSIX Compliance ticket. It
has sub-tickets for individual tasks that has been identified so far.

--joel

On Fri, Mar 16, 2018 at 1:25 PM, Salil Sirotia 
wrote:

> Hello Developers,
>
> At this point of time, I have built the newlib for SPARC BSP and
> subscribed myself for newlib mailing list.Could you please suggest me any
> library or some of the functions that is needed to port to newlib? Any
> response from your side would be
> greatly appreciated.
>
> That would be great and easy start for me towards GSoC-2018.
>
> Thanks & regards,
> Salil Sirotia,
> Mtech,CSE-IS(Final Year),
> IIT(ISM),Dhanbad
>
> ___
> 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-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

Re: Gsoc 2018

2018-03-09 Thread Gedare Bloom 
See also Aditya's comments in "Re: devel Digest, Vol 76, Issue 23"

On Fri, Mar 9, 2018 at 4:16 PM, Joel Sherrill  wrote:
> I just pushed a pretty significant update to the POSIX Compliance guide.
>
> + preface has more guidance on where to look for missing methods to
> implement
> + standards section attempts to describe each standard.
>If this section is insufficient, patches or suggestions are encouraged.
> + Added C11
> + Added FACE Technical Standard Edition 3.0 (four profiles)
> + Added Software Communications Architecture 2.2.2 (one profile)
> + Added Software Communications Architecture 4.1 (three profiles)
>
> Having this updated should help you. If you want a couple of methods
> that I think are on the easier side, look at the "utime" family. We
> have utime() and utimes() but are missing futimens() and utimesnat().
> Definitely the implementation goes in RTEMS (libc_support) and I
> think they are fairly straightforward variants on the supported methods.
>
> Adding the SPARC "fast" methods would be a good starting point
> for familiarity with newlib.
>
> Adding the fenv.h methods to newlib will be harder but rewarding
> from a methods quantity perspective. I think this involves a little
> header file surgery on the fenv.h there now and importing architecture
> specific implementations from FreeBSD and NetBSD.
>
> You will need to build tools with the RSB for every architecture you
> add fenv.h support to. Because you have to know it compiles. :)
>
> --joel
>
> On Thu, Mar 8, 2018 at 2:20 PM, Joel Sherrill  wrote:
>>
>>
>>
>> On Thu, Mar 8, 2018 at 1:27 PM, Salil Sirotia 
>> wrote:
>>>
>>>
>>> Hello Developers,
>>>
>>> This is Salil Sirotia, Doing Masters from Indian Institute of
>>> Technology, Dhanbad. I want to participate in GSoC 2018 at your
>>> organization.
>>
>>
>> Hi.. I assume you have been talking to Aditya.   :)
>>>
>>>
>>>
>>> I have gone through the RTEMS Wiki page. I have set up the environment
>>> for SPARC and edited the application "Hello World". I am attaching the
>>> Screenshot of that Application Would you like to review the same.
>>
>>
>> Awesome. Please make a patch and send it as well using git format-patch.
>>
>> Also add yourself to https://devel.rtems.org/wiki/GSoC/2018 where we
>> track what people are interested in doing.
>>
>>>
>>>
>>>
>>>
>>> I am pretty good in C/C++, Python, Shell Scripting and worked on git and
>>> GDB.
>>
>>
>> The code in the POSIX Compliance is going to all be in C. Depending on the
>> method,
>> it will need to be in Newlib (libc/libm) or RTEMS itself.  Your Python
>> would come in
>> handy in updating the generation of the POSIX Compliance document.
>>
>> The POSIX Compliance document is automatically generated from a
>> spreadsheet
>> kept in the docs git repo. This is the easiest way to find methods
>> missing.
>>
>> https://git.rtems.org/rtems-docs/tree/posix-compliance is the source
>> directory
>> in the rtems-docs
>>
>> https://docs.rtems.org/ has the generated version.
>>
>>>
>>>
>>>
>>> I have gone through the open tickets and interested in POSIX
>>> Compliance Project: https://devel.rtems.org/ticket/2966. And i already
>>> have some idea about how to build new libraries and I think i might be able
>>> to do some good work in this project Would you like to point me some docs? I
>>> am really interested in this project.
>>
>>
>> This is a moving project. :)
>>
>> Here are some odd things I know are desirable off the top of my head.
>>
>> + I would love to see fenv..h support added to newlib libm from FreeBSD.
>> + I found an assembly version of SPARC memcpy which can be merged into
>>   newlib (for SPEED).  This is from whatever OpenSolaris is called now.
>>   There may be other str* or mem* methods worth bringing over.
>> + Chris and I spotted a utime*() variant that is missing.  This would be
>>   implemented in RTEMS and it looked like the missing variant could
>>   easily be worked into the others.
>>
>> Beyond that, I would work down the FACE General Purpose Profile based
>> on the POSIX Compliance Guide. That is supposed to reflect real avionics
>> embedded systems use.
>>
>> I need to merge a new version of the tracking spreadsheet which includes
>> the recently released FACE Edition 3.0, POSIX 2003, the the Software
>> Communications Architecture profiles for 2.2.2 and 4.1. SCA was from
>> the OMG but is now from the Wireless Innovation Forum and it used
>> by software defined radios.
>>
>> I hope this sounds interesting. POSIX is a huge standard and various
>> organizations have defined profiles (e.g. subsets) of it. The moving goal
>> is to support as much as technically possible and we use the profiles
>> to guide selection of methods. It is nice to say RTEMS has all the methods
>> in XYZ profile. :)
>>
>>>
>>>
>>> Thanks & regards,
>>> Salil Sirotia,
>>>
>>>
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>>

Re: Gsoc 2018

2018-03-09 Thread Joel Sherrill 
I just pushed a pretty significant update to the POSIX Compliance guide.

+ preface has more guidance on where to look for missing methods to
implement
+ standards section attempts to describe each standard.
   If this section is insufficient, patches or suggestions are encouraged.
+ Added C11
+ Added FACE Technical Standard Edition 3.0 (four profiles)
+ Added Software Communications Architecture 2.2.2 (one profile)
+ Added Software Communications Architecture 4.1 (three profiles)

Having this updated should help you. If you want a couple of methods
that I think are on the easier side, look at the "utime" family. We
have utime() and utimes() but are missing futimens() and utimesnat().
Definitely the implementation goes in RTEMS (libc_support) and I
think they are fairly straightforward variants on the supported methods.

Adding the SPARC "fast" methods would be a good starting point
for familiarity with newlib.

Adding the fenv.h methods to newlib will be harder but rewarding
from a methods quantity perspective. I think this involves a little
header file surgery on the fenv.h there now and importing architecture
specific implementations from FreeBSD and NetBSD.

You will need to build tools with the RSB for every architecture you
add fenv.h support to. Because you have to know it compiles. :)

--joel

On Thu, Mar 8, 2018 at 2:20 PM, Joel Sherrill  wrote:

>
>
> On Thu, Mar 8, 2018 at 1:27 PM, Salil Sirotia 
> wrote:
>
>>
>> Hello Developers,
>>
>> This is Salil Sirotia, Doing Masters from Indian Institute of
>> Technology, Dhanbad. I want to participate in GSoC 2018 at your
>> organization.
>>
>
> Hi.. I assume you have been talking to Aditya.   :)
>
>>
>>
>> I have gone through the RTEMS Wiki page. I have set up the environment
>> for SPARC and edited the application "Hello World". I am attaching the
>> Screenshot of that Application Would you like to review the same.
>>
>
> Awesome. Please make a patch and send it as well using git format-patch.
>
> Also add yourself to https://devel.rtems.org/wiki/GSoC/2018 where we
> track what people are interested in doing.
>
>
>>
>>
>>
>> I am pretty good in C/C++, Python, Shell Scripting and worked on git and
>> GDB.
>>
>
> The code in the POSIX Compliance is going to all be in C. Depending on the
> method,
> it will need to be in Newlib (libc/libm) or RTEMS itself.  Your Python
> would come in
> handy in updating the generation of the POSIX Compliance document.
>
> The POSIX Compliance document is automatically generated from a spreadsheet
> kept in the docs git repo. This is the easiest way to find methods missing.
>
> https://git.rtems.org/rtems-docs/tree/posix-compliance is the source
> directory
> in the rtems-docs
>
> https://docs.rtems.org/ has the generated version.
>
>
>>
>>
>> I have gone through the open tickets and interested in POSIX
>> Compliance Project: https://devel.rtems.org/ticket/2966. And i already
>> have some idea about how to build new libraries and I think i might be
>> able to do some good work in this project Would you like to point me
>> some docs? I am really interested in this project.
>>
>
> This is a moving project. :)
>
> Here are some odd things I know are desirable off the top of my head.
>
> + I would love to see fenv..h support added to newlib libm from FreeBSD.
> + I found an assembly version of SPARC memcpy which can be merged into
>   newlib (for SPEED).  This is from whatever OpenSolaris is called now.
>   There may be other str* or mem* methods worth bringing over.
> + Chris and I spotted a utime*() variant that is missing.  This would be
>   implemented in RTEMS and it looked like the missing variant could
>   easily be worked into the others.
>
> Beyond that, I would work down the FACE General Purpose Profile based
> on the POSIX Compliance Guide. That is supposed to reflect real avionics
> embedded systems use.
>
> I need to merge a new version of the tracking spreadsheet which includes
> the recently released FACE Edition 3.0, POSIX 2003, the the Software
> Communications Architecture profiles for 2.2.2 and 4.1. SCA was from
> the OMG but is now from the Wireless Innovation Forum and it used
> by software defined radios.
>
> I hope this sounds interesting. POSIX is a huge standard and various
> organizations have defined profiles (e.g. subsets) of it. The moving goal
> is to support as much as technically possible and we use the profiles
> to guide selection of methods. It is nice to say RTEMS has all the methods
> in XYZ profile. :)
>
>
>>
>> Thanks & regards,
>> Salil Sirotia,
>>
>>
>> ___
>> 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

2018-03-08 Thread Joel Sherrill 
On Thu, Mar 8, 2018 at 1:27 PM, Salil Sirotia 
wrote:

>
> Hello Developers,
>
> This is Salil Sirotia, Doing Masters from Indian Institute of
> Technology, Dhanbad. I want to participate in GSoC 2018 at your
> organization.
>

Hi.. I assume you have been talking to Aditya.   :)

>
>
> I have gone through the RTEMS Wiki page. I have set up the environment
> for SPARC and edited the application "Hello World". I am attaching the
> Screenshot of that Application Would you like to review the same.
>

Awesome. Please make a patch and send it as well using git format-patch.

Also add yourself to https://devel.rtems.org/wiki/GSoC/2018 where we
track what people are interested in doing.


>
>
>
> I am pretty good in C/C++, Python, Shell Scripting and worked on git and
> GDB.
>

The code in the POSIX Compliance is going to all be in C. Depending on the
method,
it will need to be in Newlib (libc/libm) or RTEMS itself.  Your Python
would come in
handy in updating the generation of the POSIX Compliance document.

The POSIX Compliance document is automatically generated from a spreadsheet
kept in the docs git repo. This is the easiest way to find methods missing.

https://git.rtems.org/rtems-docs/tree/posix-compliance is the source
directory
in the rtems-docs

https://docs.rtems.org/ has the generated version.


>
>
> I have gone through the open tickets and interested in POSIX
> Compliance Project: https://devel.rtems.org/ticket/2966. And i already
> have some idea about how to build new libraries and I think i might be
> able to do some good work in this project Would you like to point me some
> docs? I am really interested in this project.
>

This is a moving project. :)

Here are some odd things I know are desirable off the top of my head.

+ I would love to see fenv..h support added to newlib libm from FreeBSD.
+ I found an assembly version of SPARC memcpy which can be merged into
  newlib (for SPEED).  This is from whatever OpenSolaris is called now.
  There may be other str* or mem* methods worth bringing over.
+ Chris and I spotted a utime*() variant that is missing.  This would be
  implemented in RTEMS and it looked like the missing variant could
  easily be worked into the others.

Beyond that, I would work down the FACE General Purpose Profile based
on the POSIX Compliance Guide. That is supposed to reflect real avionics
embedded systems use.

I need to merge a new version of the tracking spreadsheet which includes
the recently released FACE Edition 3.0, POSIX 2003, the the Software
Communications Architecture profiles for 2.2.2 and 4.1. SCA was from
the OMG but is now from the Wireless Innovation Forum and it used
by software defined radios.

I hope this sounds interesting. POSIX is a huge standard and various
organizations have defined profiles (e.g. subsets) of it. The moving goal
is to support as much as technically possible and we use the profiles
to guide selection of methods. It is nice to say RTEMS has all the methods
in XYZ profile. :)


>
> Thanks & regards,
> Salil Sirotia,
>
>
> ___
> 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 (was: Re: devel Digest, Vol 75, Issue 41)

2018-02-24 Thread Christian Mauderer 
Am 23.02.2018 um 18:19 schrieb Salil Sirotia:
> Hi all
> 
> I am more intrested in high level programming projects.Currently I am
> doing a project on wireless sensor networks in python.
> So please suggest me some Open project matching with my skills
> 
> Thanks & regards,
> Salil Sirotia,
> Mtech,CSE-IS(Final Year),
> IIT(ISM),Dhanbad

Hello Salil

please note that answering to the digests isn't really a good idea. It's
really hard to follow a thread of conversation if the topic changes
every day. Beneath that, quite a lot of users on mailing lists use a
mail client that can group messages by some special headers of a mail
(like "Message-ID", "In-Reply-To" and "References") that get lost if you
answer to digests.

Regarding the projects: If you have python experience and want to keep
at a higher level, you might want to take a look at the projects
involving the development ecosystem. That would be the ones here:


https://devel.rtems.org/wiki/Developer/OpenProjects#DevelopmentEcosystemProjects

and here:

  https://devel.rtems.org/wiki/Developer/OpenProjects#DevelopmentEcosystem

Note that the second link points to older OpenProjects that haven't been
converted to tickets yet. These projects might are not up to date.

And please remember: We don't want to select a project for you and force
you to do it. You should find one that interests you so that you can
have fun while doing the project. So if some other of the projects on
the open projects page picks your eye start to ask about it. If you
really like some framework for example for sensor networks and want to
port it to RTEMS: Suggest that as a project. Someone might think it's a
good idea too. Be creative.

Best regards

Christian Mauderer

> 
> Message: 1
> Date: Thu, 22 Feb 2018 15:48:52 +0100
> From: Christian Mauderer <christian.maude...@embedded-brains.de
> <mailto:christian.maude...@embedded-brains.de>>
> To: devel@rtems.org <mailto:devel@rtems.org>
> Subject: Re: GSOC 2018
> Message-ID: <8257435e-3cba-80df-1f42-817959fc4...@embedded-brains.de
> <mailto:8257435e-3cba-80df-1f42-817959fc4...@embedded-brains.de>>
> Content-Type: text/plain; charset=utf-8
> 
> Am 22.02.2018 um 03:35 schrieb Salil Sirotia:
> > Hi all,
> >
> > My name is Salil Sirotia and I'd like to be a part of RTEMS
> project for GSoC
> > 2018.
> >
> > As of now, I have gone through 'Getting Started documentation'
> > available on the?devel.rteme.org <http://devel.rteme.org>
> <http://devel.rteme.org/>?and have
> > managed to set up a working environment
> > for SPARC/ERC32.The wiki prospective students need to provide a proof
> > of setting up environemt,? i've sent a snapshot with the modefied
> Hello
> > World Test program after I ran it with ' sparc-rtems5-gdb ' as
> > shown on the wiki page. Please Do let me know if I need to provide
> > anything else .
> >
> > I have modified the hello world Sample application and Now I want to
> > learn more things like Open Projects in RTEMS? Organization.
> > Would you like to suggest me some Open Projects that match my skills?
> > Any suggestion would be greatly appreciated.
> >
> > I would love to work on any open projects.
> > My skills sets are :-
> > C,C++
> > Begineer in Python,Java
> >
> >
> 
> Hello Salil,
> 
> first of all: Welcome to RTEMS.
> 
> It really depends on what you would like to do. For some open projects,
> you can have a look at the OpenProjects page in the wiki:
> 
> https://devel.rtems.org/wiki/Developer/OpenProjects
> <https://devel.rtems.org/wiki/Developer/OpenProjects>
> 
> If you see something that interests you, just start to discuss it on the
> mailing list. If you have some ideas of your own you can discuss
> them too.
> 
> If you can't decide, it would be useful if you could tell us something
> more about your interests and experience. Are you interested more in
> high-level programming or something as close to hardware as possible?
> Did your already use some embedded boards like Beagle or Raspberry?
> 
> Kind regards
> 
> Christian Mauderer
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSOC 2018

2018-02-22 Thread Christian Mauderer 
Am 22.02.2018 um 03:35 schrieb Salil Sirotia:
> Hi all,
> 
> My name is Salil Sirotia and I'd like to be a part of RTEMS project for GSoC
> 2018.
> 
> As of now, I have gone through 'Getting Started documentation'
> available on the devel.rteme.org  and have
> managed to set up a working environment
> for SPARC/ERC32.The wiki prospective students need to provide a proof
> of setting up environemt,  i've sent a snapshot with the modefied Hello
> World Test program after I ran it with ' sparc-rtems5-gdb ' as
> shown on the wiki page. Please Do let me know if I need to provide
> anything else .
> 
> I have modified the hello world Sample application and Now I want to
> learn more things like Open Projects in RTEMS  Organization.
> Would you like to suggest me some Open Projects that match my skills?
> Any suggestion would be greatly appreciated.
> 
> I would love to work on any open projects.
> My skills sets are :-
> C,C++
> Begineer in Python,Java
> 
> 

Hello Salil,

first of all: Welcome to RTEMS.

It really depends on what you would like to do. For some open projects,
you can have a look at the OpenProjects page in the wiki:

https://devel.rtems.org/wiki/Developer/OpenProjects

If you see something that interests you, just start to discuss it on the
mailing list. If you have some ideas of your own you can discuss them too.

If you can't decide, it would be useful if you could tell us something
more about your interests and experience. Are you interested more in
high-level programming or something as close to hardware as possible?
Did your already use some embedded boards like Beagle or Raspberry?

Kind regards

Christian Mauderer

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
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

Re: GSoC 2018 Candidate (Patch and screenshot for hello world example)

2018-01-10 Thread Gedare Bloom 
On Wed, Jan 10, 2018 at 10:19 AM, Anshuman Chhabra
 wrote:
> Respected Mentors,
>
> I am a final year electrical engineering student at the University of Delhi,
> India. My resume is present here and my GitHub handle is anshuman23. I am
> very interested in contributing to RTEMS over the summer as part of GSoC. I
> have completed the entry level task of modifying the hello world example and
> built RTEMS for sparc/erc32. The patch is as follows:
>
> --- rtems-master/testsuites/samples/hello/init.c 2018-01-05
> 22:31:37.0 +0530
> +++ rtems/testsuites/samples/hello/init.c 2018-01-07 22:57:48.503225287
> +0530
> @@ -22,7 +22,8 @@ static rtems_task Init(
>  {
>rtems_print_printer_fprintf_putc(_test_printer);
>TEST_BEGIN();
> -  printf( "Hello World\n" );
> +  printf( "Anshuman's Hello World (GSOC 2018!)\n" );
> +  printf( "github: anshuman23\n" );
>TEST_END();
>rtems_test_exit( 0 );
>  }
>
>
>
> Where (and to whom) should I submit the screenshot? I have also looked at
Send it to me.

> the open ideas page and identified projects that interest me:
> 1. Improvements to Stack bound checker (Runtime statistics)
> 2. BSPs for simulators #2903 (QEMU Beagleboard or SkyEye edp9312)
> 3. Runtime Tracing (integration of barectf) #3028
>
> What are the required steps to complete if I am to choose one of these?
>
I suggest you should focus on projects that have been converted into
tickets, as those will tend to be higher value / more desirable.

If there is an owner on a project ticket, that is a good place to
start looking for a mentor.

> Thank you for your time,
> Warm Regards,
> Anshuman Chhabra
>
> ___
> 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