Re: discussion related to implementation of File descriptor functions in RTEMS

[Sebastian Huber]

On 25/03/2020 20:33, Joel Sherrill wrote:




On Wed, Mar 25, 2020 at 12:17 AM Eshan Dhawan > wrote:




On Wed, Mar 25, 2020 at 4:01 AM Joel Sherrill mailto:j...@rtems.org>> wrote:



On Tue, Mar 24, 2020 at 4:57 PM Eshan Dhawan
mailto:eshandhawa...@gmail.com>> wrote:

Hello everyone,
As @Vaibhav Gupta 
suggested I have also added adding file descriptor
functions to my GSOC project.
I went through the mailing list archives for more information.
RTEMS as its own file descriptor so the functions need to
be implemented from scratch.
I wanted to get more information related to it.


What's the set of functions you are proposing for those not
tracking your draft proposal?

Link:

https://docs.google.com/document/d/1n-JOFUbFn6V1kViAGWsEGbVHL9MxlMyKP0BbZhEA1Rs/edit?usp=sharing
I haven't searched about the functions in the list yet. The list
was made by Vaibhav, last year and he told me that it could be
added to proposal this year as well.
I read the archives that these need to be written from scratch.



Maybe not. I found at least this implementation of renameat() which 
was implemented on top of existing calls:


https://github.com/lattera/freebsd/blob/master/contrib/openbsm/bin/auditdistd/renameat.h

It should be in a C file but that shows it can be done. That directory 
has a lot of these methods.


Adding the *at() functions with an RTEMS-specific implementation would 
be nice (and not difficult). The generic renameat() implementation for 
example changes the current directory. One of the goals of this API is 
to avoid exactly this. In glibc/Linux for example a system call is used:


https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/renameat.c;h=901d61f37e10d0c2df245c01bb2ef980d00e8f52;hb=HEAD

https://github.com/torvalds/linux/blob/master/fs/namei.c#L4590

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

Re: [PATCH] This patch provides usage of RTEMS cross-compiler over GCC cross-compiler

[Utkarsh Rai]

Sorry, I did not look into it deeply enough. I will make the necessary
changes.

On Thu, Mar 26, 2020 at 1:44 AM Gedare Bloom  wrote:

> short commit message is a bit wordy. It doesn't need to be a sentence.
> We know it is a patch/commit.
>
> See https://devel.rtems.org/wiki/Developer/Git#GitCommits (which
> should probably be in the docs, it is linked from
> https://docs.rtems.org/branches/master/eng/vc-users.html#creating-a-patch)
>
> On Wed, Mar 25, 2020 at 12:58 PM utkarsh.ra...@gmail.com
>  wrote:
> >
> > ---
> >  user/start/tools.rst | 31 +++
> >  1 file changed, 31 insertions(+)
> >
> > diff --git a/user/start/tools.rst b/user/start/tools.rst
> > index c3f039b..c3147e8 100644
> > --- a/user/start/tools.rst
> > +++ b/user/start/tools.rst
> > @@ -76,3 +76,34 @@ source code used.
> >
> >
> >  Add ``--verbose`` to the GCC command for the the verbose version
> details.
> > +
> > +Need for RTEMS-Specific Cross-Compiler
> > +
> > +
> > +New users are often confused as to why they can't use their
> distribution's
> > +cross-compiler for their target on rtems, e.g.,the riscv64-linux-gnu or
> the
> space after comma
>
>
> > +arm-none-eabi-gcc. Below mentioned are some of the reasons for using
> the RTEMS
> > +cross-compiler.
> > +
> > + ``Correct configuration of newlib -``
> > +  Newlib is a C standard library implementation intended for use on
> embedded
> > +  systems. Most of the POSIX and libc support for RTEMS is derived from
> newlib.
> > +  The RTEMS cross-compiler configures newlib correctly for RTEMS.
> > +
> > + ``Threading in GCC support libraries -``
> > +  GCC support threading libraries such as ``pthread.h`` provide
> threading
> > +  support to an application; these libraries are tailored according to
> RTEMS using
> > +  the RTEMS cross-compiler.
> This paragraph looks wrong to me. I don't think pthread.h comes
> through gcc. We get it from newlib. But there are other threading
> packages in gcc that we need to make "RTEMS-friendly" for languages
> with threads such as Go threads (libgo) , openmp (libgomp), and maybe
> others. if you want to provide one example do a bit of research to get
> it right. It would also be possible to try to identify the exhaustive
> set but that doesn't seem necessary.
>
> > +
> > + ``Provide preprocessor define __rtems__ -``
> > +  The ``__rtems__`` preprocessor define is used to provide conditional
> code
> > +  compilation in source files that are shared with other projects e.g.
> in newlib
> > +  or imported code from freebsd.
> > +
> > + ``Multilib variants to match the BSP -``
> > +  RTEMS configures GCC to create separate runtime libraries for each
> supported
> > +  instruction set, floating point unit, vector unit, word size (e.g.
> 32-bit and
> > +  64-bit), endianness, ABI, processor errata workarounds,and so on in
> the
> space after comma
>
> I don't think we actually multilib any 32/64 bit targets, but that's
> probably fine to leave be.
>
> > +  architecture. These libraries are termed multilib variants. Multilibs
> variants
> > +  to match the BSP are set by selecting a specific set of machine
> options using
> > +  the RTEMS cross-compiler.
> > --
> > 2.17.1
> >
> > ___
> > 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 Students: Submit Draft Applications

[Gedare Bloom]

Hi Students,

I see several of you have submitted "Draft, shared" in GSoC App. That
is good, but I also want you to know that you can upload your Final
PDF multiple times before the deadline, so don't be afraid to do that
early and often.

Gedare

On Fri, Mar 20, 2020 at 4:24 PM Gedare Bloom  wrote:
>
> Hello Aspiring Students,
>
> I wanted to let you know that you can submit and revise your
> application including your "Final" proposal as many times as you like
> in the Official website, and that you should do so now and update it
> periodically until the deadline. If you don't submit it then you can't
> get picked. "Final" is not final. :)
>
> Gedare
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: discussion related to implementation of File descriptor functions in RTEMS

[Eshan Dhawan]

these are the methods I couldn't find in the compliance guide.


sys/stat.h:   int utimensat
sys/stat.h:   int _fstat
sys/_default_fcntl.h: extern int futimesat
sys/time.h:   int futimesat

The list of these methods was made by @Vaibhav Gupta
 last year by taking reference from
https://lists.rtems.org/pipermail/devel/2019-March/053149.html


On Thu, Mar 26, 2020 at 3:30 AM Joel Sherrill  wrote:

>
>
> On Wed, Mar 25, 2020 at 4:09 PM Eshan Dhawan 
> wrote:
>
>>
>>
>> On Thu, Mar 26, 2020 at 1:03 AM Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Wed, Mar 25, 2020 at 12:17 AM Eshan Dhawan 
>>> wrote:
>>>


 On Wed, Mar 25, 2020 at 4:01 AM Joel Sherrill  wrote:

>
>
> On Tue, Mar 24, 2020 at 4:57 PM Eshan Dhawan 
> wrote:
>
>> Hello everyone,
>> As @Vaibhav Gupta  suggested I have also
>> added adding file descriptor functions to my GSOC project.
>> I went through the mailing list archives for more information.
>> RTEMS as its own file descriptor so the functions need to be
>> implemented from scratch.
>> I wanted to get more information related to it.
>>
>
> What's the set of functions you are proposing for those not tracking
> your draft proposal?
>
 Link:
 https://docs.google.com/document/d/1n-JOFUbFn6V1kViAGWsEGbVHL9MxlMyKP0BbZhEA1Rs/edit?usp=sharing
 I haven't searched about the functions in the list yet. The list was
 made by Vaibhav, last year and he told me that it could be added to
 proposal this year as well.
 I read the archives that these need to be written from scratch.

>>>
>>>
>>> Maybe not. I found at least this implementation of renameat() which was
>>> implemented on top of existing calls:
>>>
>>>
>>> https://github.com/lattera/freebsd/blob/master/contrib/openbsm/bin/auditdistd/renameat.h
>>>
>>> It should be in a C file but that shows it can be done. That directory
>>> has a lot of these methods.
>>>
>>> NOTE: That list has fstat() while I am sure it should be fstatat.
>>>
>>> The list has fstatat as well.
>> I will recheck the list and will run a search to confirm that list
>> doesn't contain any function that has been already implemented  :)
>>
>
> The COmpliance Guide is an easy place to search for things. Grep for like
> "at()" and ignore methods like strcat(). :)
>
>>
>>> I would move these up the list since they look easy to port from that
>>> source. Convert them from .h to .c, and we can discuss adding them to
>>> newlib.
>>>
>>> @Aditya Upadhyay  told that need to be added to
>> RTEMS libbsd
>>
>
> That is the most straightforward way to import non-essential POSIX methods
> that we are taking from FreeBSD. But the implementation I found listed
> above appears to be completely portable and not require any new system
> calls or peeks below POSIX APIs. These are not frequently used methods and
> adding them would be good for all newlib users this way.
>
> We just didn't find that implementation in the past. I'm thrilled it
> exists. Easier to add.
>
> --joel
>
>>
>>> --joel
>>>


>> thanks
>> -Eshan
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: discussion related to implementation of File descriptor functions in RTEMS

[Joel Sherrill]

On Wed, Mar 25, 2020 at 4:09 PM Eshan Dhawan 
wrote:

>
>
> On Thu, Mar 26, 2020 at 1:03 AM Joel Sherrill  wrote:
>
>>
>>
>> On Wed, Mar 25, 2020 at 12:17 AM Eshan Dhawan 
>> wrote:
>>
>>>
>>>
>>> On Wed, Mar 25, 2020 at 4:01 AM Joel Sherrill  wrote:
>>>


 On Tue, Mar 24, 2020 at 4:57 PM Eshan Dhawan 
 wrote:

> Hello everyone,
> As @Vaibhav Gupta  suggested I have also
> added adding file descriptor functions to my GSOC project.
> I went through the mailing list archives for more information.
> RTEMS as its own file descriptor so the functions need to be
> implemented from scratch.
> I wanted to get more information related to it.
>

 What's the set of functions you are proposing for those not tracking
 your draft proposal?

>>> Link:
>>> https://docs.google.com/document/d/1n-JOFUbFn6V1kViAGWsEGbVHL9MxlMyKP0BbZhEA1Rs/edit?usp=sharing
>>> I haven't searched about the functions in the list yet. The list was
>>> made by Vaibhav, last year and he told me that it could be added to
>>> proposal this year as well.
>>> I read the archives that these need to be written from scratch.
>>>
>>
>>
>> Maybe not. I found at least this implementation of renameat() which was
>> implemented on top of existing calls:
>>
>>
>> https://github.com/lattera/freebsd/blob/master/contrib/openbsm/bin/auditdistd/renameat.h
>>
>> It should be in a C file but that shows it can be done. That directory
>> has a lot of these methods.
>>
>> NOTE: That list has fstat() while I am sure it should be fstatat.
>>
>> The list has fstatat as well.
> I will recheck the list and will run a search to confirm that list doesn't
> contain any function that has been already implemented  :)
>

The COmpliance Guide is an easy place to search for things. Grep for like
"at()" and ignore methods like strcat(). :)

>
>> I would move these up the list since they look easy to port from that
>> source. Convert them from .h to .c, and we can discuss adding them to
>> newlib.
>>
>> @Aditya Upadhyay  told that need to be added to
> RTEMS libbsd
>

That is the most straightforward way to import non-essential POSIX methods
that we are taking from FreeBSD. But the implementation I found listed
above appears to be completely portable and not require any new system
calls or peeks below POSIX APIs. These are not frequently used methods and
adding them would be good for all newlib users this way.

We just didn't find that implementation in the past. I'm thrilled it
exists. Easier to add.

--joel

>
>> --joel
>>
>>>
>>>
> thanks
> -Eshan
>

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

Re: discussion related to implementation of File descriptor functions in RTEMS

[Eshan Dhawan]

On Thu, Mar 26, 2020 at 1:03 AM Joel Sherrill  wrote:

>
>
> On Wed, Mar 25, 2020 at 12:17 AM Eshan Dhawan 
> wrote:
>
>>
>>
>> On Wed, Mar 25, 2020 at 4:01 AM Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Tue, Mar 24, 2020 at 4:57 PM Eshan Dhawan 
>>> wrote:
>>>
 Hello everyone,
 As @Vaibhav Gupta  suggested I have also
 added adding file descriptor functions to my GSOC project.
 I went through the mailing list archives for more information.
 RTEMS as its own file descriptor so the functions need to be
 implemented from scratch.
 I wanted to get more information related to it.

>>>
>>> What's the set of functions you are proposing for those not tracking
>>> your draft proposal?
>>>
>> Link:
>> https://docs.google.com/document/d/1n-JOFUbFn6V1kViAGWsEGbVHL9MxlMyKP0BbZhEA1Rs/edit?usp=sharing
>> I haven't searched about the functions in the list yet. The list was made
>> by Vaibhav, last year and he told me that it could be added to proposal
>> this year as well.
>> I read the archives that these need to be written from scratch.
>>
>
>
> Maybe not. I found at least this implementation of renameat() which was
> implemented on top of existing calls:
>
>
> https://github.com/lattera/freebsd/blob/master/contrib/openbsm/bin/auditdistd/renameat.h
>
> It should be in a C file but that shows it can be done. That directory has
> a lot of these methods.
>
> NOTE: That list has fstat() while I am sure it should be fstatat.
>
> The list has fstatat as well.
I will recheck the list and will run a search to confirm that list doesn't
contain any function that has been already implemented  :)

>
> I would move these up the list since they look easy to port from that
> source. Convert them from .h to .c, and we can discuss adding them to
> newlib.
>
> @Aditya Upadhyay  told that need to be added to
RTEMS libbsd

>
> --joel
>
>>
>>
 thanks
 -Eshan

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

Re: Update POSIX compliance guide

[Joel Sherrill]

On Wed, Mar 25, 2020 at 3:43 PM Eshan Dhawan 
wrote:

>
>
> On Thu, Mar 26, 2020 at 1:49 AM Gedare Bloom  wrote:
>
>> On Wed, Mar 25, 2020 at 1:21 PM Joel Sherrill  wrote:
>> >
>> >
>> >
>> > On Wed, Mar 25, 2020 at 12:59 PM Eshan Dhawan 
>> wrote:
>> >>
>> >> I went through the implementations in FreeBSD, NetBSD and musl
>> >> they all require fork().
>> >> So they can't be used by RTEMS.
>> >
>> >
>> > Read
>> https://pubs.opengroup.org/onlinepubs/9699919799/functions/wordexp.html
>> and see
>> > that it even includes an example of how you could implement this using
>> forking
>> > echo and using pipes to capture the output.
>> >
>> It's not required though. We can do a clean implementation of it
>> without fork, and provide some use case with RTEMS shell. This would
>> be a nice bit of coding work for GSoC beyond porting/fixup. I'd
>> strongly encourage it.
>>
> I have added it to the list and starting to study more about it.
>


OK. The POSIX description sounds brutal but 

Takes a library that can do wildcard and environment variable expansion as
a minimum.


>
>> > I'm open to ideas on a small string to put in the Compliance
>> spreadsheet to mark
>> > methods that we will never support. All of the posix_spawn() and this
>> fall into that
>> > category. This would help avoid this analysis happening again.
>> >
>> > And once we figure that out, I hope I can figure out the magic in the
>> Python script
>> > that generates the document from the spreadsheet. :)
>> >
>> > Gedare.. do you think we should add a section to the POSIX Users Guide
>> on
>> > Unsupportable Methods? Not full man pages but maybe a subsection per
>> header
>> > file with unsupportable methods, the list of methods and some rationale?
>> >
>> Wouldn't hurt. It'll take some doing though, and isn't appropriate as
>> a GSoC milestone but could be a side-contribution.
>>
>
I may go ahead and add a chapter so at least it is easier to add sections.


>
>> >>
>> >>
>> >> On Wed, Mar 25, 2020 at 11:17 PM Gedare Bloom 
>> wrote:
>> >>>
>> >>> Hi Eshan,
>> >>>
>> >>> We can work with the newlib community. Some things can be done in
>> >>> newlib that are only for RTEMS, while some things we should share with
>> >>> others, and still more code may be not useable by RTEMS (e.g., what is
>> >>> in sys/linux). It is best to try to make common code available, but if
>> >>> some code has to be specialized for RTEMS differently than how it
>> >>> works in other systems then we can do that.
>> >>>
>> >>> Gedare
>> >>>
>> >>> On Wed, Mar 25, 2020 at 11:06 AM Eshan Dhawan <
>> eshandhawa...@gmail.com> wrote:
>> >>> >
>> >>> > I will check the musl for a more RTEMS  supported implementation.
>> >>> > but will newlib change the implementation??
>> >>> >
>> >>> > On Wed, Mar 25, 2020 at 8:26 PM Joel Sherrill 
>> wrote:
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >> On Sun, Mar 22, 2020 at 2:00 PM Eshan Dhawan <
>> eshandhawa...@gmail.com> wrote:
>> >>> >>>
>> >>> >>> I have also checked wordexp.h is completely present in newlib
>> (libc/include)
>> >>> >>> the implementation of the functions wordexp.c and wordfree.c  is
>> in (libc/posix)
>> >>> >>> But the compliance status shows not supported.
>> >>> >>
>> >>> >>
>> >>> >> I don't see them in libc.a for the sparc:
>> >>> >>
>> >>> >> lib_a-wordexp.o:
>> >>> >>
>> >>> >> lib_a-wordfree.o:
>> >>> >>
>> >>> >>
>> >>> >> It is not included in RTEMS because the newlib implementation
>> requires multiple
>> >>> >> processes. It uses fork() and pipes.
>> >>> >>
>> >>> >> Maybe MUSCL has an implementation that is embedded friendly but
>> the compliance
>> >>> >> guide is correct.
>> >>> >>
>> >>> >> --joel
>> >>> >>
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> >>> >>> On Sat, Mar 21, 2020 at 11:31 PM Joel Sherrill 
>> wrote:
>> >>> 
>> >>> 
>> >>> 
>> >>> 
>> >>>  On Sat, Mar 21, 2020, 8:47 AM Eshan Dhawan <
>> eshandhawa...@gmail.com> wrote:
>> >>> >
>> >>> > Hello everyone
>> >>> >
>> >>> > I went through the POSIX Compliance guide and it showed that
>> wcsncasecmp_l () was not supported in wchar.h
>> >>> > But when I checked newlib it had been implemented in libc/string
>> >>> > so I think it needs to be updated in the docs.
>> >>> 
>> >>> 
>> >>>  Thanks for spotting this. I did a spot check and think there
>> were a few more wc* methods that were not in the spreadsheet. I am going to
>> post a patch in a bit.  Please check it.
>> >>> 
>> >>>  Obviously, this is a csv file maintained externally in a
>> spreadsheet. If you put it in a spreadsheet, you can turn on data filtering
>> based on the top row. Then you can do "queries" to do things like filter
>> down to what's in a single header file. Or what's required in one standard
>> but not in another.
>> >>> 
>> >>>  FWIW this turned into a bit of a rat hole. I tried to double
>> check the newlib git repo and the link on their website is wrong after the
>> upgrade of sourceware.org. Then checked gdb 

Re: Update POSIX compliance guide

[Eshan Dhawan]

On Thu, Mar 26, 2020 at 1:49 AM Gedare Bloom  wrote:

> On Wed, Mar 25, 2020 at 1:21 PM Joel Sherrill  wrote:
> >
> >
> >
> > On Wed, Mar 25, 2020 at 12:59 PM Eshan Dhawan 
> wrote:
> >>
> >> I went through the implementations in FreeBSD, NetBSD and musl
> >> they all require fork().
> >> So they can't be used by RTEMS.
> >
> >
> > Read
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/wordexp.html
> and see
> > that it even includes an example of how you could implement this using
> forking
> > echo and using pipes to capture the output.
> >
> It's not required though. We can do a clean implementation of it
> without fork, and provide some use case with RTEMS shell. This would
> be a nice bit of coding work for GSoC beyond porting/fixup. I'd
> strongly encourage it.
>
I have added it to the list and starting to study more about it.

>
> > I'm open to ideas on a small string to put in the Compliance spreadsheet
> to mark
> > methods that we will never support. All of the posix_spawn() and this
> fall into that
> > category. This would help avoid this analysis happening again.
> >
> > And once we figure that out, I hope I can figure out the magic in the
> Python script
> > that generates the document from the spreadsheet. :)
> >
> > Gedare.. do you think we should add a section to the POSIX Users Guide on
> > Unsupportable Methods? Not full man pages but maybe a subsection per
> header
> > file with unsupportable methods, the list of methods and some rationale?
> >
> Wouldn't hurt. It'll take some doing though, and isn't appropriate as
> a GSoC milestone but could be a side-contribution.
>
> >>
> >>
> >> On Wed, Mar 25, 2020 at 11:17 PM Gedare Bloom  wrote:
> >>>
> >>> Hi Eshan,
> >>>
> >>> We can work with the newlib community. Some things can be done in
> >>> newlib that are only for RTEMS, while some things we should share with
> >>> others, and still more code may be not useable by RTEMS (e.g., what is
> >>> in sys/linux). It is best to try to make common code available, but if
> >>> some code has to be specialized for RTEMS differently than how it
> >>> works in other systems then we can do that.
> >>>
> >>> Gedare
> >>>
> >>> On Wed, Mar 25, 2020 at 11:06 AM Eshan Dhawan 
> wrote:
> >>> >
> >>> > I will check the musl for a more RTEMS  supported implementation.
> >>> > but will newlib change the implementation??
> >>> >
> >>> > On Wed, Mar 25, 2020 at 8:26 PM Joel Sherrill 
> wrote:
> >>> >>
> >>> >>
> >>> >>
> >>> >> On Sun, Mar 22, 2020 at 2:00 PM Eshan Dhawan <
> eshandhawa...@gmail.com> wrote:
> >>> >>>
> >>> >>> I have also checked wordexp.h is completely present in newlib
> (libc/include)
> >>> >>> the implementation of the functions wordexp.c and wordfree.c  is
> in (libc/posix)
> >>> >>> But the compliance status shows not supported.
> >>> >>
> >>> >>
> >>> >> I don't see them in libc.a for the sparc:
> >>> >>
> >>> >> lib_a-wordexp.o:
> >>> >>
> >>> >> lib_a-wordfree.o:
> >>> >>
> >>> >>
> >>> >> It is not included in RTEMS because the newlib implementation
> requires multiple
> >>> >> processes. It uses fork() and pipes.
> >>> >>
> >>> >> Maybe MUSCL has an implementation that is embedded friendly but the
> compliance
> >>> >> guide is correct.
> >>> >>
> >>> >> --joel
> >>> >>
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>> On Sat, Mar 21, 2020 at 11:31 PM Joel Sherrill 
> wrote:
> >>> 
> >>> 
> >>> 
> >>> 
> >>>  On Sat, Mar 21, 2020, 8:47 AM Eshan Dhawan <
> eshandhawa...@gmail.com> wrote:
> >>> >
> >>> > Hello everyone
> >>> >
> >>> > I went through the POSIX Compliance guide and it showed that
> wcsncasecmp_l () was not supported in wchar.h
> >>> > But when I checked newlib it had been implemented in libc/string
> >>> > so I think it needs to be updated in the docs.
> >>> 
> >>> 
> >>>  Thanks for spotting this. I did a spot check and think there were
> a few more wc* methods that were not in the spreadsheet. I am going to post
> a patch in a bit.  Please check it.
> >>> 
> >>>  Obviously, this is a csv file maintained externally in a
> spreadsheet. If you put it in a spreadsheet, you can turn on data filtering
> based on the top row. Then you can do "queries" to do things like filter
> down to what's in a single header file. Or what's required in one standard
> but not in another.
> >>> 
> >>>  FWIW this turned into a bit of a rat hole. I tried to double
> check the newlib git repo and the link on their website is wrong after the
> upgrade of sourceware.org. Then checked gdb and it had the same issue.
> This resulted in also reporting some leftover cleanup from the recent
> upgrade of sourceware.org.
> >>> >
> >>> >
> >>> > Thanks
> >>> > Eshan
> >>> >
> >>> > ___
> >>> > devel mailing list
> >>> > devel@rtems.org
> >>> > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org

Re: Update POSIX compliance guide

[Gedare Bloom]

On Wed, Mar 25, 2020 at 1:21 PM Joel Sherrill  wrote:
>
>
>
> On Wed, Mar 25, 2020 at 12:59 PM Eshan Dhawan  wrote:
>>
>> I went through the implementations in FreeBSD, NetBSD and musl
>> they all require fork().
>> So they can't be used by RTEMS.
>
>
> Read https://pubs.opengroup.org/onlinepubs/9699919799/functions/wordexp.html 
> and see
> that it even includes an example of how you could implement this using forking
> echo and using pipes to capture the output.
>
It's not required though. We can do a clean implementation of it
without fork, and provide some use case with RTEMS shell. This would
be a nice bit of coding work for GSoC beyond porting/fixup. I'd
strongly encourage it.

> I'm open to ideas on a small string to put in the Compliance spreadsheet to 
> mark
> methods that we will never support. All of the posix_spawn() and this fall 
> into that
> category. This would help avoid this analysis happening again.
>
> And once we figure that out, I hope I can figure out the magic in the Python 
> script
> that generates the document from the spreadsheet. :)
>
> Gedare.. do you think we should add a section to the POSIX Users Guide on
> Unsupportable Methods? Not full man pages but maybe a subsection per header
> file with unsupportable methods, the list of methods and some rationale?
>
Wouldn't hurt. It'll take some doing though, and isn't appropriate as
a GSoC milestone but could be a side-contribution.

>>
>>
>> On Wed, Mar 25, 2020 at 11:17 PM Gedare Bloom  wrote:
>>>
>>> Hi Eshan,
>>>
>>> We can work with the newlib community. Some things can be done in
>>> newlib that are only for RTEMS, while some things we should share with
>>> others, and still more code may be not useable by RTEMS (e.g., what is
>>> in sys/linux). It is best to try to make common code available, but if
>>> some code has to be specialized for RTEMS differently than how it
>>> works in other systems then we can do that.
>>>
>>> Gedare
>>>
>>> On Wed, Mar 25, 2020 at 11:06 AM Eshan Dhawan  
>>> wrote:
>>> >
>>> > I will check the musl for a more RTEMS  supported implementation.
>>> > but will newlib change the implementation??
>>> >
>>> > On Wed, Mar 25, 2020 at 8:26 PM Joel Sherrill  wrote:
>>> >>
>>> >>
>>> >>
>>> >> On Sun, Mar 22, 2020 at 2:00 PM Eshan Dhawan  
>>> >> wrote:
>>> >>>
>>> >>> I have also checked wordexp.h is completely present in newlib 
>>> >>> (libc/include)
>>> >>> the implementation of the functions wordexp.c and wordfree.c  is in 
>>> >>> (libc/posix)
>>> >>> But the compliance status shows not supported.
>>> >>
>>> >>
>>> >> I don't see them in libc.a for the sparc:
>>> >>
>>> >> lib_a-wordexp.o:
>>> >>
>>> >> lib_a-wordfree.o:
>>> >>
>>> >>
>>> >> It is not included in RTEMS because the newlib implementation requires 
>>> >> multiple
>>> >> processes. It uses fork() and pipes.
>>> >>
>>> >> Maybe MUSCL has an implementation that is embedded friendly but the 
>>> >> compliance
>>> >> guide is correct.
>>> >>
>>> >> --joel
>>> >>
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Sat, Mar 21, 2020 at 11:31 PM Joel Sherrill  wrote:
>>> 
>>> 
>>> 
>>> 
>>>  On Sat, Mar 21, 2020, 8:47 AM Eshan Dhawan  
>>>  wrote:
>>> >
>>> > Hello everyone
>>> >
>>> > I went through the POSIX Compliance guide and it showed that  
>>> > wcsncasecmp_l () was not supported in wchar.h
>>> > But when I checked newlib it had been implemented in libc/string
>>> > so I think it needs to be updated in the docs.
>>> 
>>> 
>>>  Thanks for spotting this. I did a spot check and think there were a 
>>>  few more wc* methods that were not in the spreadsheet. I am going to 
>>>  post a patch in a bit.  Please check it.
>>> 
>>>  Obviously, this is a csv file maintained externally in a spreadsheet. 
>>>  If you put it in a spreadsheet, you can turn on data filtering based 
>>>  on the top row. Then you can do "queries" to do things like filter 
>>>  down to what's in a single header file. Or what's required in one 
>>>  standard but not in another.
>>> 
>>>  FWIW this turned into a bit of a rat hole. I tried to double check the 
>>>  newlib git repo and the link on their website is wrong after the 
>>>  upgrade of sourceware.org. Then checked gdb and it had the same issue. 
>>>  This resulted in also reporting some leftover cleanup from the recent 
>>>  upgrade of sourceware.org.
>>> >
>>> >
>>> > Thanks
>>> > Eshan
>>> >
>>> > ___
>>> > 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: [PATCH] This patch provides usage of RTEMS cross-compiler over GCC cross-compiler

[Gedare Bloom]

short commit message is a bit wordy. It doesn't need to be a sentence.
We know it is a patch/commit.

See https://devel.rtems.org/wiki/Developer/Git#GitCommits (which
should probably be in the docs, it is linked from
https://docs.rtems.org/branches/master/eng/vc-users.html#creating-a-patch)

On Wed, Mar 25, 2020 at 12:58 PM utkarsh.ra...@gmail.com
 wrote:
>
> ---
>  user/start/tools.rst | 31 +++
>  1 file changed, 31 insertions(+)
>
> diff --git a/user/start/tools.rst b/user/start/tools.rst
> index c3f039b..c3147e8 100644
> --- a/user/start/tools.rst
> +++ b/user/start/tools.rst
> @@ -76,3 +76,34 @@ source code used.
>
>
>  Add ``--verbose`` to the GCC command for the the verbose version details.
> +
> +Need for RTEMS-Specific Cross-Compiler
> +
> +
> +New users are often confused as to why they can't use their distribution's
> +cross-compiler for their target on rtems, e.g.,the riscv64-linux-gnu or the
space after comma


> +arm-none-eabi-gcc. Below mentioned are some of the reasons for using the 
> RTEMS
> +cross-compiler.
> +
> + ``Correct configuration of newlib -``
> +  Newlib is a C standard library implementation intended for use on embedded
> +  systems. Most of the POSIX and libc support for RTEMS is derived from 
> newlib.
> +  The RTEMS cross-compiler configures newlib correctly for RTEMS.
> +
> + ``Threading in GCC support libraries -``
> +  GCC support threading libraries such as ``pthread.h`` provide threading
> +  support to an application; these libraries are tailored according to RTEMS 
> using
> +  the RTEMS cross-compiler.
This paragraph looks wrong to me. I don't think pthread.h comes
through gcc. We get it from newlib. But there are other threading
packages in gcc that we need to make "RTEMS-friendly" for languages
with threads such as Go threads (libgo) , openmp (libgomp), and maybe
others. if you want to provide one example do a bit of research to get
it right. It would also be possible to try to identify the exhaustive
set but that doesn't seem necessary.

> +
> + ``Provide preprocessor define __rtems__ -``
> +  The ``__rtems__`` preprocessor define is used to provide conditional code
> +  compilation in source files that are shared with other projects e.g. in 
> newlib
> +  or imported code from freebsd.
> +
> + ``Multilib variants to match the BSP -``
> +  RTEMS configures GCC to create separate runtime libraries for each 
> supported
> +  instruction set, floating point unit, vector unit, word size (e.g. 32-bit 
> and
> +  64-bit), endianness, ABI, processor errata workarounds,and so on in the
space after comma

I don't think we actually multilib any 32/64 bit targets, but that's
probably fine to leave be.

> +  architecture. These libraries are termed multilib variants. Multilibs 
> variants
> +  to match the BSP are set by selecting a specific set of machine options 
> using
> +  the RTEMS cross-compiler.
> --
> 2.17.1
>
> ___
> 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: discussion related to ipc.h

[Eshan Dhawan]

> On 26-Mar-2020, at 12:42 AM, Joel Sherrill  wrote:
> 
> 
> No need to put discussion in the subject. As Gedare pointed out, all email 
> threads are discussions by definition. ;)
> 
>> On Wed, Mar 25, 2020 at 1:32 PM Eshan Dhawan  wrote:
>> Hello everyone,
>> 
>> I went through the implementation of sys/ipc.h in various platforms.
>> From FreeBSD, it is difficult to implement file as warned by Joel.
>> but then I went through musl implementation 
>> it is easy to comprehend 
>> But it has a kind of architecture-specific implementation.
>> 
>> FreeBSD 
>> > ipc.h : https://github.com/freebsd/freebsd/blob/master/sys/sys/ipc.h
>> > ftok.c: https://github.com/freebsd/freebsd/blob/master/lib/libc/gen/ftok.c
>> musl 
>> > https://git.musl-libc.org/cgit/musl/tree/src/ipc 
>> https://git.musl-libc.org/cgit/musl/tree/include/sys/ipc.h
>> and a ipc.h file , ipcstat.h in arch/MACHINE/bits 
>> Generic 
>> https://git.musl-libc.org/cgit/musl/tree/arch/generic/bits/ipc.h
>> https://git.musl-libc.org/cgit/musl/tree/arch/generic/bits/ipcstat.h 
>> 
>> ipcstat.h has a different value for every arch. 
> 
> On closer reading, ftok() support without the other IPC mechanisms makes
> no sense.  I would push this one way way down the list -- like stay as far
> away from ipc.h as you can this summer. :)
> 
Ok,got that ;) 
> --joel
>> 
>> thanks 
>> eshan
>> ___
>> 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: discussion related to implementation of File descriptor functions in RTEMS

[Joel Sherrill]

On Wed, Mar 25, 2020 at 12:17 AM Eshan Dhawan 
wrote:

>
>
> On Wed, Mar 25, 2020 at 4:01 AM Joel Sherrill  wrote:
>
>>
>>
>> On Tue, Mar 24, 2020 at 4:57 PM Eshan Dhawan 
>> wrote:
>>
>>> Hello everyone,
>>> As @Vaibhav Gupta  suggested I have also
>>> added adding file descriptor functions to my GSOC project.
>>> I went through the mailing list archives for more information.
>>> RTEMS as its own file descriptor so the functions need to be implemented
>>> from scratch.
>>> I wanted to get more information related to it.
>>>
>>
>> What's the set of functions you are proposing for those not tracking your
>> draft proposal?
>>
> Link:
> https://docs.google.com/document/d/1n-JOFUbFn6V1kViAGWsEGbVHL9MxlMyKP0BbZhEA1Rs/edit?usp=sharing
> I haven't searched about the functions in the list yet. The list was made
> by Vaibhav, last year and he told me that it could be added to proposal
> this year as well.
> I read the archives that these need to be written from scratch.
>


Maybe not. I found at least this implementation of renameat() which was
implemented on top of existing calls:

https://github.com/lattera/freebsd/blob/master/contrib/openbsm/bin/auditdistd/renameat.h

It should be in a C file but that shows it can be done. That directory has
a lot of these methods.

NOTE: That list has fstat() while I am sure it should be fstatat.

I would move these up the list since they look easy to port from that
source. Convert them from .h to .c, and we can discuss adding them to
newlib.

--joel

>
>
>>> thanks
>>> -Eshan
>>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Update POSIX compliance guide

[Joel Sherrill]

On Wed, Mar 25, 2020 at 12:59 PM Eshan Dhawan 
wrote:

> I went through the implementations in FreeBSD, NetBSD and musl
> they all require fork().
> So they can't be used by RTEMS.
>

Read https://pubs.opengroup.org/onlinepubs/9699919799/functions/wordexp.html
and
see
that it even includes an example of how you could implement this using
forking
echo and using pipes to capture the output.

I'm open to ideas on a small string to put in the Compliance spreadsheet to
mark
methods that we will never support. All of the posix_spawn() and this fall
into that
category. This would help avoid this analysis happening again.

And once we figure that out, I hope I can figure out the magic in the
Python script
that generates the document from the spreadsheet. :)

Gedare.. do you think we should add a section to the POSIX Users Guide on
Unsupportable Methods? Not full man pages but maybe a subsection per header
file with unsupportable methods, the list of methods and some rationale?


>
> On Wed, Mar 25, 2020 at 11:17 PM Gedare Bloom  wrote:
>
>> Hi Eshan,
>>
>> We can work with the newlib community. Some things can be done in
>> newlib that are only for RTEMS, while some things we should share with
>> others, and still more code may be not useable by RTEMS (e.g., what is
>> in sys/linux). It is best to try to make common code available, but if
>> some code has to be specialized for RTEMS differently than how it
>> works in other systems then we can do that.
>>
>> Gedare
>>
>> On Wed, Mar 25, 2020 at 11:06 AM Eshan Dhawan 
>> wrote:
>> >
>> > I will check the musl for a more RTEMS  supported implementation.
>> > but will newlib change the implementation??
>> >
>> > On Wed, Mar 25, 2020 at 8:26 PM Joel Sherrill  wrote:
>> >>
>> >>
>> >>
>> >> On Sun, Mar 22, 2020 at 2:00 PM Eshan Dhawan 
>> wrote:
>> >>>
>> >>> I have also checked wordexp.h is completely present in newlib
>> (libc/include)
>> >>> the implementation of the functions wordexp.c and wordfree.c  is in
>> (libc/posix)
>> >>> But the compliance status shows not supported.
>> >>
>> >>
>> >> I don't see them in libc.a for the sparc:
>> >>
>> >> lib_a-wordexp.o:
>> >>
>> >> lib_a-wordfree.o:
>> >>
>> >>
>> >> It is not included in RTEMS because the newlib implementation requires
>> multiple
>> >> processes. It uses fork() and pipes.
>> >>
>> >> Maybe MUSCL has an implementation that is embedded friendly but the
>> compliance
>> >> guide is correct.
>> >>
>> >> --joel
>> >>
>> >>>
>> >>>
>> >>>
>> >>> On Sat, Mar 21, 2020 at 11:31 PM Joel Sherrill 
>> wrote:
>> 
>> 
>> 
>> 
>>  On Sat, Mar 21, 2020, 8:47 AM Eshan Dhawan 
>> wrote:
>> >
>> > Hello everyone
>> >
>> > I went through the POSIX Compliance guide and it showed that
>> wcsncasecmp_l () was not supported in wchar.h
>> > But when I checked newlib it had been implemented in libc/string
>> > so I think it needs to be updated in the docs.
>> 
>> 
>>  Thanks for spotting this. I did a spot check and think there were a
>> few more wc* methods that were not in the spreadsheet. I am going to post a
>> patch in a bit.  Please check it.
>> 
>>  Obviously, this is a csv file maintained externally in a
>> spreadsheet. If you put it in a spreadsheet, you can turn on data filtering
>> based on the top row. Then you can do "queries" to do things like filter
>> down to what's in a single header file. Or what's required in one standard
>> but not in another.
>> 
>>  FWIW this turned into a bit of a rat hole. I tried to double check
>> the newlib git repo and the link on their website is wrong after the
>> upgrade of sourceware.org. Then checked gdb and it had the same issue.
>> This resulted in also reporting some leftover cleanup from the recent
>> upgrade of sourceware.org.
>> >
>> >
>> > Thanks
>> > Eshan
>> >
>> > ___
>> > 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: discussion related to ipc.h

[Joel Sherrill]

No need to put discussion in the subject. As Gedare pointed out, all email
threads are discussions by definition. ;)

On Wed, Mar 25, 2020 at 1:32 PM Eshan Dhawan 
wrote:

> Hello everyone,
>
> I went through the implementation of sys/ipc.h in various platforms.
> From FreeBSD, it is difficult to implement file as warned by Joel.
> but then I went through musl implementation
> it is easy to comprehend
> But it has a kind of architecture-specific implementation.
>
> FreeBSD
> > ipc.h : https://github.com/freebsd/freebsd/blob/master/sys/sys/ipc.h
> > ftok.c:
> https://github.com/freebsd/freebsd/blob/master/lib/libc/gen/ftok.c
> musl
> > https://git.musl-libc.org/cgit/musl/tree/src/ipc
> https://git.musl-libc.org/cgit/musl/tree/include/sys/ipc.h
> and a ipc.h file , ipcstat.h in arch/MACHINE/bits
> Generic
> https://git.musl-libc.org/cgit/musl/tree/arch/generic/bits/ipc.h
> https://git.musl-libc.org/cgit/musl/tree/arch/generic/bits/ipcstat.h
>
> ipcstat.h has a different value for every arch.
>

On closer reading, ftok() support without the other IPC mechanisms makes
no sense.  I would push this one way way down the list -- like stay as far
away from ipc.h as you can this summer. :)

--joel

>
> thanks
> eshan
> ___
> 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

[PATCH] This patch provides usage of RTEMS cross-compiler over GCC cross-compiler

[utkarsh.ra...@gmail.com]

---
 user/start/tools.rst | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/user/start/tools.rst b/user/start/tools.rst
index c3f039b..c3147e8 100644
--- a/user/start/tools.rst
+++ b/user/start/tools.rst
@@ -76,3 +76,34 @@ source code used.
 
 
 Add ``--verbose`` to the GCC command for the the verbose version details.
+
+Need for RTEMS-Specific Cross-Compiler
+
+ 
+New users are often confused as to why they can't use their distribution's
+cross-compiler for their target on rtems, e.g.,the riscv64-linux-gnu or the
+arm-none-eabi-gcc. Below mentioned are some of the reasons for using the RTEMS
+cross-compiler.
+
+ ``Correct configuration of newlib -`` 
+  Newlib is a C standard library implementation intended for use on embedded
+  systems. Most of the POSIX and libc support for RTEMS is derived from newlib.
+  The RTEMS cross-compiler configures newlib correctly for RTEMS.
+
+ ``Threading in GCC support libraries -`` 
+  GCC support threading libraries such as ``pthread.h`` provide threading
+  support to an application; these libraries are tailored according to RTEMS 
using
+  the RTEMS cross-compiler.
+   
+ ``Provide preprocessor define __rtems__ -``  
+  The ``__rtems__`` preprocessor define is used to provide conditional code
+  compilation in source files that are shared with other projects e.g. in 
newlib
+  or imported code from freebsd.
+
+ ``Multilib variants to match the BSP -`` 
+  RTEMS configures GCC to create separate runtime libraries for each supported
+  instruction set, floating point unit, vector unit, word size (e.g. 32-bit and
+  64-bit), endianness, ABI, processor errata workarounds,and so on in the
+  architecture. These libraries are termed multilib variants. Multilibs 
variants
+  to match the BSP are set by selecting a specific set of machine options using
+  the RTEMS cross-compiler.
-- 
2.17.1

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

Re: discussion related to source for porting headers and methods to RTEMS and newlib

[Eshan Dhawan]

On Wed, Mar 25, 2020 at 4:40 PM Eshan Dhawan 
wrote:

>
>
> On Wed, Mar 25, 2020 at 4:18 AM Joel Sherrill  wrote:
>
>>
>>
>> On Tue, Mar 24, 2020 at 5:33 PM Gedare Bloom  wrote:
>>
>>> email subject can be shortened. almost everything is a discussion :)
>>>
>>> On Tue, Mar 24, 2020 at 3:49 PM Eshan Dhawan 
>>> wrote:
>>> >
>>> > Hello everyone,
>>> > I have identified sources to port headers and methods to RTEMS and
>>> Newlib. I have given priority to FreeBSD for the choice of source. But
>>> method not present in FreeBSD can be ported from alternative sources like
>>> NetBSD and musl.
>>> >
>>> Considering the simplicity, you may want to compare musl vs freebsd as
>>> well.
>>>
>>> > -> Missing methods of math.h: I have compiled a list of methods and
>>> their sources. Some need to be implemented from scratch.
>>> > list: Math.h missing functions
>>> >
>>> > -> sys/ipc.h: This header and its function can be ported from FreeBSD.
>>> > ipc.h : https://github.com/freebsd/freebsd/blob/master/sys/sys/ipc.h
>>> > ftok.c:
>>> https://github.com/freebsd/freebsd/blob/master/lib/libc/gen/ftok.c
>>
>>
>> sys/ipc.h has a lot in it. If you head down the path of adding sys/ipc.h,
>> you need to evaluate what else is in the file.
>>
>> Adding support for the System V style SHM, Semaphores, or Message Queues
>> is possible (I think) but is definitely harder than the likely value to the
>> community.
>>
> I would like to know missing headers and methods that would be more
> valuable to the community
>
>>
>>> >
>>> > ->fmtmsg.h: its implementation is also present in FreeBSD.
>>> > https://github.com/freebsd/freebsd/blob/master/include/fmtmsg.h
>>> > https://github.com/freebsd/freebsd/blob/master/lib/libc/gen/fmtmsg.c
>>
>>
>> By my recollection, this would be a discrete thing to add to Newlib.
>>
>>>
>>> >
>>> > ->spawn.h: Its implementation is in FreeBSD.
>>> >
>>> https://github.com/freebsd/freebsd/blob/master/lib/libc/gen/posix_spawn.c
>>> >
>>> I'm worried about the large number of includes there. It may easily
>>> lead you to trouble chasing down transitive include headers, like what
>>> happened with Vaibhav before with search.h support.
>>>
>>
>> posix_spawn() cannot be supported by RTEMS. It is a new safer way to do
>> fork/exec. Don't spent any time on this. It will never work on RTEMS.
>>
>> It is also a HUGE amount of methods and constants. :(
>>
> Ok I will remove it from the proposal
>
>>
>>> > -> pselect() from  : its implementation is also from
>>> FreeBSD
>>> > https://github.com/freebsd/freebsd/blob/master/lib/libc/sys/pselect.c
>>
>>
>> This would be added to rtems-libbsd. There may be specific technical
>> challenges
>> why it is not present. Or it could just be an oversight.
>>
> I haven't dig that deep.
>
> it is present in RTEMS libbsd
but the compliance docs show that the function is still not implemented
https://docs.rtems.org/branches/master/posix-compliance/posix-compliance.html#sys-select-h

>
>>
>>>
>>> >
>>> > -> confstr() from : Its implementation is from FreeBSD
>>> > https://github.com/udp/freebsd-libc/blob/master/gen/confstr.c.
>>>
>>
>> The implementation of this would go in RTEMS.
>>
>> It is possible that the FreeBSD code is a guide but this cannot be a
>> direct
>> copy to port. Each value defined by POSIX as fetchable must be properly
>> defined for RTEMS. You would need to make a table of all the "names"
>> that can be looked up in your proposal.
>>
> what would be better writing it from scratch of just doing minor tweaks in
> the FreeBSD code
> We also have an option to take code from musl
> https://git.musl-libc.org/cgit/musl/tree/src/conf/confstr.c
>
>>
>> FWIW I think the FreeBSD version is more right than wrong for RTEMS
>> but it can't be 100% right and needs analysis.
>>
>> >
>>> > I would like everyone to review it and provide your suggestions.
>>> >
>>> include details in your proposal also.
>>>
>>
>> +1
>> I have already added these detatils to the proposal
>> but will change spawn.h
>>
>>>
>>> > Thanks
>>> > -Eshan
>>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

discussion related to ipc.h

[Eshan Dhawan]

Hello everyone,

I went through the implementation of sys/ipc.h in various platforms.
>From FreeBSD, it is difficult to implement file as warned by Joel.
but then I went through musl implementation
it is easy to comprehend
But it has a kind of architecture-specific implementation.

FreeBSD
> ipc.h : https://github.com/freebsd/freebsd/blob/master/sys/sys/ipc.h
> ftok.c: https://github.com/freebsd/freebsd/blob/master/lib/libc/gen/ftok.c
musl
> https://git.musl-libc.org/cgit/musl/tree/src/ipc
https://git.musl-libc.org/cgit/musl/tree/include/sys/ipc.h
and a ipc.h file , ipcstat.h in arch/MACHINE/bits
Generic
https://git.musl-libc.org/cgit/musl/tree/arch/generic/bits/ipc.h
https://git.musl-libc.org/cgit/musl/tree/arch/generic/bits/ipcstat.h

ipcstat.h has a different value for every arch.

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

Re: Update POSIX compliance guide

[Eshan Dhawan]

I went through the implementations in FreeBSD, NetBSD and musl
they all require fork().
So they can't be used by RTEMS.

On Wed, Mar 25, 2020 at 11:17 PM Gedare Bloom  wrote:

> Hi Eshan,
>
> We can work with the newlib community. Some things can be done in
> newlib that are only for RTEMS, while some things we should share with
> others, and still more code may be not useable by RTEMS (e.g., what is
> in sys/linux). It is best to try to make common code available, but if
> some code has to be specialized for RTEMS differently than how it
> works in other systems then we can do that.
>
> Gedare
>
> On Wed, Mar 25, 2020 at 11:06 AM Eshan Dhawan 
> wrote:
> >
> > I will check the musl for a more RTEMS  supported implementation.
> > but will newlib change the implementation??
> >
> > On Wed, Mar 25, 2020 at 8:26 PM Joel Sherrill  wrote:
> >>
> >>
> >>
> >> On Sun, Mar 22, 2020 at 2:00 PM Eshan Dhawan 
> wrote:
> >>>
> >>> I have also checked wordexp.h is completely present in newlib
> (libc/include)
> >>> the implementation of the functions wordexp.c and wordfree.c  is in
> (libc/posix)
> >>> But the compliance status shows not supported.
> >>
> >>
> >> I don't see them in libc.a for the sparc:
> >>
> >> lib_a-wordexp.o:
> >>
> >> lib_a-wordfree.o:
> >>
> >>
> >> It is not included in RTEMS because the newlib implementation requires
> multiple
> >> processes. It uses fork() and pipes.
> >>
> >> Maybe MUSCL has an implementation that is embedded friendly but the
> compliance
> >> guide is correct.
> >>
> >> --joel
> >>
> >>>
> >>>
> >>>
> >>> On Sat, Mar 21, 2020 at 11:31 PM Joel Sherrill  wrote:
> 
> 
> 
> 
>  On Sat, Mar 21, 2020, 8:47 AM Eshan Dhawan 
> wrote:
> >
> > Hello everyone
> >
> > I went through the POSIX Compliance guide and it showed that
> wcsncasecmp_l () was not supported in wchar.h
> > But when I checked newlib it had been implemented in libc/string
> > so I think it needs to be updated in the docs.
> 
> 
>  Thanks for spotting this. I did a spot check and think there were a
> few more wc* methods that were not in the spreadsheet. I am going to post a
> patch in a bit.  Please check it.
> 
>  Obviously, this is a csv file maintained externally in a spreadsheet.
> If you put it in a spreadsheet, you can turn on data filtering based on the
> top row. Then you can do "queries" to do things like filter down to what's
> in a single header file. Or what's required in one standard but not in
> another.
> 
>  FWIW this turned into a bit of a rat hole. I tried to double check
> the newlib git repo and the link on their website is wrong after the
> upgrade of sourceware.org. Then checked gdb and it had the same issue.
> This resulted in also reporting some leftover cleanup from the recent
> upgrade of sourceware.org.
> >
> >
> > Thanks
> > Eshan
> >
> > ___
> > 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: Update POSIX compliance guide

[Gedare Bloom]

Hi Eshan,

We can work with the newlib community. Some things can be done in
newlib that are only for RTEMS, while some things we should share with
others, and still more code may be not useable by RTEMS (e.g., what is
in sys/linux). It is best to try to make common code available, but if
some code has to be specialized for RTEMS differently than how it
works in other systems then we can do that.

Gedare

On Wed, Mar 25, 2020 at 11:06 AM Eshan Dhawan  wrote:
>
> I will check the musl for a more RTEMS  supported implementation.
> but will newlib change the implementation??
>
> On Wed, Mar 25, 2020 at 8:26 PM Joel Sherrill  wrote:
>>
>>
>>
>> On Sun, Mar 22, 2020 at 2:00 PM Eshan Dhawan  wrote:
>>>
>>> I have also checked wordexp.h is completely present in newlib (libc/include)
>>> the implementation of the functions wordexp.c and wordfree.c  is in 
>>> (libc/posix)
>>> But the compliance status shows not supported.
>>
>>
>> I don't see them in libc.a for the sparc:
>>
>> lib_a-wordexp.o:
>>
>> lib_a-wordfree.o:
>>
>>
>> It is not included in RTEMS because the newlib implementation requires 
>> multiple
>> processes. It uses fork() and pipes.
>>
>> Maybe MUSCL has an implementation that is embedded friendly but the 
>> compliance
>> guide is correct.
>>
>> --joel
>>
>>>
>>>
>>>
>>> On Sat, Mar 21, 2020 at 11:31 PM Joel Sherrill  wrote:




 On Sat, Mar 21, 2020, 8:47 AM Eshan Dhawan  wrote:
>
> Hello everyone
>
> I went through the POSIX Compliance guide and it showed that  
> wcsncasecmp_l () was not supported in wchar.h
> But when I checked newlib it had been implemented in libc/string
> so I think it needs to be updated in the docs.


 Thanks for spotting this. I did a spot check and think there were a few 
 more wc* methods that were not in the spreadsheet. I am going to post a 
 patch in a bit.  Please check it.

 Obviously, this is a csv file maintained externally in a spreadsheet. If 
 you put it in a spreadsheet, you can turn on data filtering based on the 
 top row. Then you can do "queries" to do things like filter down to what's 
 in a single header file. Or what's required in one standard but not in 
 another.

 FWIW this turned into a bit of a rat hole. I tried to double check the 
 newlib git repo and the link on their website is wrong after the upgrade 
 of sourceware.org. Then checked gdb and it had the same issue. This 
 resulted in also reporting some leftover cleanup from the recent upgrade 
 of sourceware.org.
>
>
> Thanks
> Eshan
>
> ___
> 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: Update POSIX compliance guide

[Eshan Dhawan]

I will check the musl for a more RTEMS  supported implementation.
but will newlib change the implementation??

On Wed, Mar 25, 2020 at 8:26 PM Joel Sherrill  wrote:

>
>
> On Sun, Mar 22, 2020 at 2:00 PM Eshan Dhawan 
> wrote:
>
>> I have also checked wordexp.h is completely present in newlib
>> (libc/include)
>> the implementation of the functions wordexp.c and wordfree.c  is in
>> (libc/posix)
>> But the compliance status shows not supported.
>>
>
> I don't see them in libc.a for the sparc:
>
> lib_a-wordexp.o:
>
> lib_a-wordfree.o:
>
>
> It is not included in RTEMS because the newlib implementation requires
> multiple
> processes. It uses fork() and pipes.
>
> Maybe MUSCL has an implementation that is embedded friendly but the
> compliance
> guide is correct.
>
> --joel
>
>
>>
>>
>> On Sat, Mar 21, 2020 at 11:31 PM Joel Sherrill  wrote:
>>
>>>
>>>
>>>
>>> On Sat, Mar 21, 2020, 8:47 AM Eshan Dhawan 
>>> wrote:
>>>
 Hello everyone

 I went through the POSIX Compliance guide and it showed that
 wcsncasecmp_l () was not supported in wchar.h
 But when I checked newlib it had been implemented in libc/string
 so I think it needs to be updated in the docs.

>>>
>>> Thanks for spotting this. I did a spot check and think there were a few
>>> more wc* methods that were not in the spreadsheet. I am going to post a
>>> patch in a bit.  Please check it.
>>>
>>> Obviously, this is a csv file maintained externally in a spreadsheet. If
>>> you put it in a spreadsheet, you can turn on data filtering based on the
>>> top row. Then you can do "queries" to do things like filter down to what's
>>> in a single header file. Or what's required in one standard but not in
>>> another.
>>>
>>> FWIW this turned into a bit of a rat hole. I tried to double check the
>>> newlib git repo and the link on their website is wrong after the upgrade of
>>> sourceware.org. Then checked gdb and it had the same issue. This
>>> resulted in also reporting some leftover cleanup from the recent upgrade of
>>> sourceware.org.
>>>

 Thanks
 Eshan

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

Re: [PATCH] MAINTAINERS: Add myself to Write After Approval

[Vijay Kumar Banerjee]

On Wed, Mar 25, 2020, 8:30 PM Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:

> On 25/03/2020 15:59, Vijay Kumar Banerjee wrote:
> >
> >
> > On Wed, Mar 25, 2020 at 8:16 PM Gedare Bloom  > > wrote:
> >
> > Looks good, please push.
> >
> > Pushed! :)
>
> Congratulations. Your maintainer status is now officially documented.
>

Thanks!!

>
> Best regards
>
> Christian
>
> >
> > On Tue, Mar 24, 2020 at 1:49 PM Vijay Kumar Banerjee
> > mailto:vi...@rtems.org>> wrote:
> > >
> > > ---
> > >  MAINTAINERS | 2 ++
> > >  1 file changed, 2 insertions(+)
> > >
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index 437b55418b..29e22357a5 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -52,6 +52,7 @@ Pavel Pisa pp...@pikron.com
> > 
> > >  Christian Mauderer christian.maude...@embedded-brains.de
> > 
> > >  Hesham Almataryheshamelmat...@gmail.com
> > 
> > >  Amaan Cheval   am...@rtems.org  am...@rtems.org>
> > > +Vijay Kumar Banerjee   vi...@rtems.org  vi...@rtems.org>
> > >
> > >  Localized Write Permission
> > >  ==
> > > @@ -60,4 +61,5 @@ beagle Ben Gras
> > (b...@rtems.org )
> > >  tms570 Pavel Pisa (p...@cmp.felk.cvut.cz
> > )
> > >  raspberrypiPavel Pisa (p...@cmp.felk.cvut.cz
> > )
> > >  x86_64 Amaan Cheval (am...@rtems.org
> > )
> > > +beagle Vijay Kumar Banerjee (vi...@rtems.org
> > )
> > >
> > > --
> > > 2.21.1
> > >
> > > ___
> > > 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
> >
>
> --
> 
> 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: [PATCH] MAINTAINERS: Add myself to Write After Approval

[Christian Mauderer]

On 25/03/2020 15:59, Vijay Kumar Banerjee wrote:
> 
> 
> On Wed, Mar 25, 2020 at 8:16 PM Gedare Bloom  > wrote:
> 
> Looks good, please push.
> 
> Pushed! :) 

Congratulations. Your maintainer status is now officially documented.

Best regards

Christian

> 
> On Tue, Mar 24, 2020 at 1:49 PM Vijay Kumar Banerjee
> mailto:vi...@rtems.org>> wrote:
> >
> > ---
> >  MAINTAINERS | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 437b55418b..29e22357a5 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -52,6 +52,7 @@ Pavel Pisa                 pp...@pikron.com
> 
> >  Christian Mauderer         christian.maude...@embedded-brains.de
> 
> >  Hesham Almatary            heshamelmat...@gmail.com
> 
> >  Amaan Cheval               am...@rtems.org 
> > +Vijay Kumar Banerjee       vi...@rtems.org 
> >
> >  Localized Write Permission
> >  ==
> > @@ -60,4 +61,5 @@ beagle                     Ben Gras
> (b...@rtems.org )
> >  tms570                     Pavel Pisa (p...@cmp.felk.cvut.cz
> )
> >  raspberrypi                Pavel Pisa (p...@cmp.felk.cvut.cz
> )
> >  x86_64                     Amaan Cheval (am...@rtems.org
> )
> > +beagle                     Vijay Kumar Banerjee (vi...@rtems.org
> )
> >
> > --
> > 2.21.1
> >
> > ___
> > 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
> 

-- 

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: [PATCH] MAINTAINERS: Add myself to Write After Approval

[Vijay Kumar Banerjee]

On Wed, Mar 25, 2020 at 8:16 PM Gedare Bloom  wrote:

> Looks good, please push.
>
> Pushed! :)

> On Tue, Mar 24, 2020 at 1:49 PM Vijay Kumar Banerjee 
> wrote:
> >
> > ---
> >  MAINTAINERS | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 437b55418b..29e22357a5 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -52,6 +52,7 @@ Pavel Pisa pp...@pikron.com
> >  Christian Mauderer christian.maude...@embedded-brains.de
> >  Hesham Almataryheshamelmat...@gmail.com
> >  Amaan Cheval   am...@rtems.org
> > +Vijay Kumar Banerjee   vi...@rtems.org
> >
> >  Localized Write Permission
> >  ==
> > @@ -60,4 +61,5 @@ beagle Ben Gras (b...@rtems.org)
> >  tms570 Pavel Pisa (p...@cmp.felk.cvut.cz)
> >  raspberrypiPavel Pisa (p...@cmp.felk.cvut.cz)
> >  x86_64 Amaan Cheval (am...@rtems.org)
> > +beagle Vijay Kumar Banerjee (vi...@rtems.org)
> >
> > --
> > 2.21.1
> >
> > ___
> > 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: Update POSIX compliance guide

[Joel Sherrill]

On Sun, Mar 22, 2020 at 2:00 PM Eshan Dhawan 
wrote:

> I have also checked wordexp.h is completely present in newlib
> (libc/include)
> the implementation of the functions wordexp.c and wordfree.c  is in
> (libc/posix)
> But the compliance status shows not supported.
>

I don't see them in libc.a for the sparc:

lib_a-wordexp.o:

lib_a-wordfree.o:


It is not included in RTEMS because the newlib implementation requires
multiple
processes. It uses fork() and pipes.

Maybe MUSCL has an implementation that is embedded friendly but the
compliance
guide is correct.

--joel


>
>
> On Sat, Mar 21, 2020 at 11:31 PM Joel Sherrill  wrote:
>
>>
>>
>>
>> On Sat, Mar 21, 2020, 8:47 AM Eshan Dhawan 
>> wrote:
>>
>>> Hello everyone
>>>
>>> I went through the POSIX Compliance guide and it showed that
>>> wcsncasecmp_l () was not supported in wchar.h
>>> But when I checked newlib it had been implemented in libc/string
>>> so I think it needs to be updated in the docs.
>>>
>>
>> Thanks for spotting this. I did a spot check and think there were a few
>> more wc* methods that were not in the spreadsheet. I am going to post a
>> patch in a bit.  Please check it.
>>
>> Obviously, this is a csv file maintained externally in a spreadsheet. If
>> you put it in a spreadsheet, you can turn on data filtering based on the
>> top row. Then you can do "queries" to do things like filter down to what's
>> in a single header file. Or what's required in one standard but not in
>> another.
>>
>> FWIW this turned into a bit of a rat hole. I tried to double check the
>> newlib git repo and the link on their website is wrong after the upgrade of
>> sourceware.org. Then checked gdb and it had the same issue. This
>> resulted in also reporting some leftover cleanup from the recent upgrade of
>> sourceware.org.
>>
>>>
>>> Thanks
>>> Eshan
>>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] MAINTAINERS: Add myself to Write After Approval

[Gedare Bloom]

Looks good, please push.

On Tue, Mar 24, 2020 at 1:49 PM Vijay Kumar Banerjee  wrote:
>
> ---
>  MAINTAINERS | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 437b55418b..29e22357a5 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -52,6 +52,7 @@ Pavel Pisa pp...@pikron.com
>  Christian Mauderer christian.maude...@embedded-brains.de
>  Hesham Almataryheshamelmat...@gmail.com
>  Amaan Cheval   am...@rtems.org
> +Vijay Kumar Banerjee   vi...@rtems.org
>
>  Localized Write Permission
>  ==
> @@ -60,4 +61,5 @@ beagle Ben Gras (b...@rtems.org)
>  tms570 Pavel Pisa (p...@cmp.felk.cvut.cz)
>  raspberrypiPavel Pisa (p...@cmp.felk.cvut.cz)
>  x86_64 Amaan Cheval (am...@rtems.org)
> +beagle Vijay Kumar Banerjee (vi...@rtems.org)
>
> --
> 2.21.1
>
> ___
> 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: discussion related to source for porting headers and methods to RTEMS and newlib

[Eshan Dhawan]

On Wed, Mar 25, 2020 at 4:18 AM Joel Sherrill  wrote:

>
>
> On Tue, Mar 24, 2020 at 5:33 PM Gedare Bloom  wrote:
>
>> email subject can be shortened. almost everything is a discussion :)
>>
>> On Tue, Mar 24, 2020 at 3:49 PM Eshan Dhawan 
>> wrote:
>> >
>> > Hello everyone,
>> > I have identified sources to port headers and methods to RTEMS and
>> Newlib. I have given priority to FreeBSD for the choice of source. But
>> method not present in FreeBSD can be ported from alternative sources like
>> NetBSD and musl.
>> >
>> Considering the simplicity, you may want to compare musl vs freebsd as
>> well.
>>
>> > -> Missing methods of math.h: I have compiled a list of methods and
>> their sources. Some need to be implemented from scratch.
>> > list: Math.h missing functions
>> >
>> > -> sys/ipc.h: This header and its function can be ported from FreeBSD.
>> > ipc.h : https://github.com/freebsd/freebsd/blob/master/sys/sys/ipc.h
>> > ftok.c:
>> https://github.com/freebsd/freebsd/blob/master/lib/libc/gen/ftok.c
>
>
> sys/ipc.h has a lot in it. If you head down the path of adding sys/ipc.h,
> you need to evaluate what else is in the file.
>
> Adding support for the System V style SHM, Semaphores, or Message Queues
> is possible (I think) but is definitely harder than the likely value to the
> community.
>
I would like to know missing headers and methods that would be more
valuable to the community

>
>> >
>> > ->fmtmsg.h: its implementation is also present in FreeBSD.
>> > https://github.com/freebsd/freebsd/blob/master/include/fmtmsg.h
>> > https://github.com/freebsd/freebsd/blob/master/lib/libc/gen/fmtmsg.c
>
>
> By my recollection, this would be a discrete thing to add to Newlib.
>
>>
>> >
>> > ->spawn.h: Its implementation is in FreeBSD.
>> >
>> https://github.com/freebsd/freebsd/blob/master/lib/libc/gen/posix_spawn.c
>> >
>> I'm worried about the large number of includes there. It may easily
>> lead you to trouble chasing down transitive include headers, like what
>> happened with Vaibhav before with search.h support.
>>
>
> posix_spawn() cannot be supported by RTEMS. It is a new safer way to do
> fork/exec. Don't spent any time on this. It will never work on RTEMS.
>
> It is also a HUGE amount of methods and constants. :(
>
Ok I will remove it from the proposal

>
>> > -> pselect() from  : its implementation is also from
>> FreeBSD
>> > https://github.com/freebsd/freebsd/blob/master/lib/libc/sys/pselect.c
>
>
> This would be added to rtems-libbsd. There may be specific technical
> challenges
> why it is not present. Or it could just be an oversight.
>
I haven't dig that deep.

>
>
>>
>> >
>> > -> confstr() from : Its implementation is from FreeBSD
>> > https://github.com/udp/freebsd-libc/blob/master/gen/confstr.c.
>>
>
> The implementation of this would go in RTEMS.
>
> It is possible that the FreeBSD code is a guide but this cannot be a direct
> copy to port. Each value defined by POSIX as fetchable must be properly
> defined for RTEMS. You would need to make a table of all the "names"
> that can be looked up in your proposal.
>
what would be better writing it from scratch of just doing minor tweaks in
the FreeBSD code
We also have an option to take code from musl
https://git.musl-libc.org/cgit/musl/tree/src/conf/confstr.c

>
> FWIW I think the FreeBSD version is more right than wrong for RTEMS
> but it can't be 100% right and needs analysis.
>
> >
>> > I would like everyone to review it and provide your suggestions.
>> >
>> include details in your proposal also.
>>
>
> +1
> I have already added these detatils to the proposal
> but will change spawn.h
>
>>
>> > Thanks
>> > -Eshan
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems-examples PATCH v2 1/2] Update rtems_waf

[Chris Johns]

On 2020-03-25 07:19, Vijay Kumar Banerjee wrote:
On Thu, Mar 19, 2020 at 7:54 AM Chris Johns > wrote:


Both these patches are fine to push. Vijay, please push once your
access has
been sorted out.

Pushed this!


Nice and thanks :)

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