<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 25, 2021 at 7:14 AM Matthew Joyce <<a href="mailto:mfjoyce2004@gmail.com">mfjoyce2004@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Dr. Joel,<br>
<br>
Thanks very much, that's a big help!  Correct, I've been updating the<br>
spreadsheet as I go along. Ok, now I see that strlcat/strlcpy are used<br>
in rtems/cpukit and implemented in Newlib.<br>
<br>
One additional question, please: I haven't yet looked into the source<br>
of NetBSD or FreeBSD, but I do see that Newlib already implements<br>
ppoll (poll.cc), dladdr (dlfcn.cc), pselect (select.cc), and<br>
sockatmark (net.cc). None of them are defined in the rtems environment<br>
yet. Is there any reason why the NetBSD/FreeBSD version would be<br>
preferable to Newlib for these? Or is it just a matter of testing<br>
what's out there to find what works well in the rtems environment?<br></blockquote><div><br></div><div>Without looking at the newlib git repo, I can tell you that the files</div><div>you cite are the implementation of those methods for Cygwin. Just</div><div>because they are in C++. :)</div><div><br></div><div>The parts of the newlib repo RTEMS uses are under the newlib/ </div><div>subdirectory not the cygwin one. Within that, there is a libc/sys and</div><div>only libc/sys/rtems is used for RTEMS. The others are for different</div><div>operating systems. There are a few places with "machine" directory</div><div>structures. Only the ones for the architecture you are building for</div><div>is used. </div><div><br></div><div>As to why NetBSD for libdl, that is because portions of the code </div><div>originated there.</div><div><br></div><div>And rtems-libbsd is based on FreeBSD. It is as close to the FreeBSD</div><div>source as we can keep it. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
In my proposal I'll take your advice and work on some of the easier<br>
ones first in order to get the experience and process down.<br></blockquote><div><br></div><div>There are tickets for a lot of methods. The rtems-docs repo has the</div><div>csv file (e.g. spreadsheet) which tracks RTEMS support against </div><div>various standards. The RTEMS POSIX Compliance Guide is generated</div><div>from that csv file. Between those, you can find other methods to ask</div><div>about. In general, if it is required by the Software Communications</div><div>Architecture (SCA) or FACE Technical Standard, then it is a method</div><div>someone expected to possibly be used in an embedded system.</div><div>SCA is a set of POSIX profiles focused on software defined radios and</div><div>the FACE Technical Standard was developed with avionics in mind.</div><div><br></div><div>But any are fair game if they are actually implementable. I don;t think</div><div>the Compliance Guide says it yet, but we decided last year that </div><div>wordexp() is likely not supportable on RTEMS. The newlib </div><div>implementation assumes the presence of a shell with wildcard expansion</div><div>and ability to fork a process.</div><div><br></div><div>--joel</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Thank you again for your time!<br>
<br>
Matt<br>
<br>
On Wed, Mar 24, 2021 at 5:03 PM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>> wrote:<br>
><br>
> Wow! Good work. There is a lot to digest here. Comments interspersed.<br>
><br>
> I assume the spreadsheet is updated.<br>
><br>
> On Wed, Mar 24, 2021 at 7:38 AM Matthew Joyce <<a href="mailto:mfjoyce2004@gmail.com" target="_blank">mfjoyce2004@gmail.com</a>> wrote:<br>
>><br>
>> Hi Dr. Joel,<br>
>><br>
>> I've gone over the list a few times now and see a few categories shaping up:<br>
>><br>
>> 1) Already done (In Newlib source, defined in libc.a):<br>
>> a) reallocarray<br>
>> b) qsort_r<br>
>> c) memmem<br>
>> d) strlcat / strlcpy<br>
>> d) wcslcat / wcslcpy<br>
>> *Out of this group, strlcat and strlcpy also show up in<br>
>> src/rtems/cpukit. Why is that?<br>
><br>
><br>
> The good news is that we support these. :)<br>
><br>
> It looks to me that strlcat and strlcpy are used in cpukit but not implemented<br>
> there. Where do you think they are implemented.<br>
><br>
> This is a good example where a source code browser is helpful. grep can<br>
> often answer the question but a source code browser can be easier. Personally,<br>
> I use cscope but that is exceedingly old school. Any modern IDE should be<br>
> helpful.<br>
><br>
>><br>
>> 2) Not done yet (Do not show up in Newlib source or RTEMS):<br>
>> a) getlocalename_l<br>
>> b) posix_getdents<br>
>> c) sem_clockwait<br>
>> d) sig2str / str2sig<br>
>><br>
>> 3) Not in Newlib; Referenced in RTEMS but hidden behind #ifdef:<br>
>> a) pthread_cond_clockwait<br>
>> (rtems/6/lib/gcc/sparc-rtems6/10.2.1/include/c++/condition_variable)<br>
>> b) pthread_mutex_clocklock<br>
>> (rtems/6/lib/gcc/sparc-rtems6/10.2.1/include/c++/mutex)<br>
>> c) pthread_rwlock_clockrdlock<br>
>> (rtems/6/lib/gcc/sparc-rtems6/10.2.1/include/c++/shared_mutex)<br>
>> c) pthread_rwlock_clockwrlock<br>
>> (rtems/6/lib/gcc/sparc-rtems6/10.2.1/include/c++/shared_mutex)<br>
>> *It looks like some groundwork was done, but the methods are not yet supported.<br>
><br>
><br>
> The paths you point to are C++ files that would implement C++ features<br>
> using the available POSIX services. So they are users, not providers.<br>
><br>
> All of the pthread services related to these are implemented in<br>
> cpukit/posix/src. I think you can configure a clock for all these now<br>
> to be used by detailed on wait and timedwait calls. My understanding<br>
> is that these would let you use a specific clock on a per blocking call<br>
> basis.<br>
><br>
> First question is which clocks are intended to be supported.<br>
><br>
> Second is the pattern of picking which timeout queue to go on when<br>
> now it is coded to let you pick one which is used for the life of the object.<br>
><br>
>><br>
>> 4) Misc (In Newlib source, not defined in libc.a, appear in RTEMS in<br>
>> various ways)<br>
>> a) getentropy (an alternate version is defined in RTEMS librtemsbsd.a,<br>
>> in src/rtems/bsps/shared/dev/getentropy/getentropy-cpucounter.c. The<br>
>> comments note that it is not cryptographically secure, so it may not<br>
>> fit the bill for the getentropy() mentioned in the Open Group<br>
>> document)<br>
><br>
><br>
> I am far from a cryptography expert but this looks like a case where<br>
> this method would be considered supported with the disclaimer that<br>
> the quality of the entropy value depends on the BSP. If the user has<br>
> specific requirements, they will need to verify the implementation<br>
> used by the BSP by default is appropriate.<br>
><br>
>><br>
>> b) ppoll (appears in rtems/6/share/gdb/syscalls)<br>
><br>
><br>
> You need to be more careful with the grep. These again are in the<br>
> installed tools and in this case, they appear in an XML file. Referenced<br>
> but not implemented.<br>
><br>
> ppoll() will need to come from rtems-libbsd. The required system call<br>
> is included but disabled currently. AFAIK this means it is possible to<br>
> provide this but that would require a more detailed discussion in case<br>
> some underlying capability is missing. Chris Johns and Sebastian<br>
> Huber would be the ones to guide here.<br>
><br>
> Ruling: Likely possible.<br>
><br>
>><br>
>> c) dladdr (appears in rtems/cpukit but not defined)<br>
><br>
><br>
> I think this can be implemented in libdl but I am not sure if the<br>
> code from NetBSD from this would directly work or just be a guide.<br>
><br>
>><br>
>><br>
>> 5) Others?<br>
>> It looks like there was work done on methods like sockatmark and<br>
>> pselect, but I don't see them supported as yet. Should those be added<br>
>> to the list or are they still being worked on?<br>
><br>
><br>
> These would come from rtems-libbsd.<br>
><br>
> I think sockatmark.c is implemented in freebsd/lib/libc/net/sockatmark.c<br>
> but I don't know if the ioctl() is implemented. I expect it is but this would<br>
> at least require a test. It may just work.<br>
><br>
> pselect() looks to be missing and would have to be ported from FreeBSD.<br>
><br>
>><br>
>> As you suggested, I'll look into NetBSD for dladdr and do some digging<br>
>> on the implementation of the other outstanding methods. You mentioned<br>
>> that the "clock" ones have to be strictly added to rtems/cpukit, but<br>
>> the references I found above are all in lib/gcc/sparc-rtems6/<a href="http://10.2.1." rel="noreferrer" target="_blank">10.2.1.</a><br>
>> Why is that the case and what is 10.2.1? Also, I'm not sure what to<br>
>> make of getentropy and ppoll based on what I found above...at your<br>
>> convenience could you please advise?<br>
><br>
><br>
> Hopefully the above helped.<br>
><br>
> You don't have to restrict your possible set to these new additions.<br>
> There are others. I think Eshan has done the research for where to<br>
> get implementations of the missing long double methods for newlib.<br>
> And there are tickets for other missing methods or specific capabilities<br>
> in methods that are supported. Those are quite possible to have<br>
> some alternatives that are easier to approach.<br>
><br>
> --joel<br>
><br>
><br>
>><br>
>><br>
>> Thank you very much!<br>
>><br>
>> Matt<br>
>><br>
>><br>
>><br>
>><br>
>> On Sun, Mar 21, 2021 at 6:38 PM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>> wrote:<br>
>> ><br>
>> ><br>
>> ><br>
>> > On Sun, Mar 21, 2021 at 2:28 AM Matthew Joyce <<a href="mailto:mfjoyce2004@gmail.com" target="_blank">mfjoyce2004@gmail.com</a>> wrote:<br>
>> >><br>
>> >> Gentlemen,<br>
>> >><br>
>> >> Awesome, thanks!  I see how that works now...I'll give it a thorough<br>
>> >> look tomorrow and will update the spreadsheet accordingly. I'll pipe<br>
>> >> back up when I have a more accurate look of what's currently there.<br>
>> ><br>
>> ><br>
>> > Knowing what doesn't have to be done is the first step. (rtems, newlib, and libbsd)<br>
>> ><br>
>> > I'd be prone to look for things that are easy to add first.<br>
>> ><br>
>> > Some may not be implementable on RTEMS due to only supporting a<br>
>> > single process and no virtual memory. If you have doubts on whether it<br>
>> > is possible to support a specific method, speak up and let's try to decide.<br>
>> ><br>
>> > Then find upstream places for an implementation where possible. I suspect<br>
>> > all the new "clock" methods will require discussion on an implementation<br>
>> > pattern but those must strictly be added to rtems/cpukit with tests and<br>
>> > documentation. At least I can throw you that much. :)<br>
>> ><br>
>> >><br>
>> >> Thanks again and have a great Sunday!<br>
>> >><br>
>> >> Matt<br>
>> >><br>
>> >> On Fri, Mar 19, 2021 at 8:27 PM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>> wrote:<br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> > On Fri, Mar 19, 2021 at 1:08 PM Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>> wrote:<br>
>> >> >><br>
>> >> >> On Fri, Mar 19, 2021 at 11:16 AM Matthew Joyce <<a href="mailto:mfjoyce2004@gmail.com" target="_blank">mfjoyce2004@gmail.com</a>> wrote:<br>
>> >> >> ><br>
>> >> >> > Dr. Joel,<br>
>> >> >> ><br>
>> >> >> > Thanks very much...I'll keep working to get a sense of what goes<br>
>> >> >> > where! In the meantime, where can I look to get the ground truth of<br>
>> >> >> > which methods are "in RTEMS" as opposed to those in newlib?<br>
>> >> >> ><br>
>> >> >> There is only one ground truth:<br>
>> >> >> git://<a href="http://git.rtems.org/rtems.git" rel="noreferrer" target="_blank">git.rtems.org/rtems.git</a><br>
>> >> >><br>
>> >> >> And for newlib<br>
>> >> >><br>
>> >> >> git://<a href="http://sourceware.org/git/newlib-cygwin.git" rel="noreferrer" target="_blank">sourceware.org/git/newlib-cygwin.git</a><br>
>> >> >><br>
>> >> >> That said, searching for the function name symbols in compiled<br>
>> >> >> libraries is a good first step to rule out newlib. Then, you can<br>
>> >> >> 'grep' the RTEMS source code for the function names to see if they<br>
>> >> >> exist there.<br>
>> >> ><br>
>> >> ><br>
>> >> > rtems/cpukit to be specitic. It won't be implemented anywhere else.<br>
>> >> ><br>
>> >> > And clearly we both have forgotten that networking APIs are in the<br>
>> >> > rtems-libbsd repository.<br>
>> >> ><br>
>> >> > <a href="https://git.rtems.org/rtems-libbsd/" rel="noreferrer" target="_blank">https://git.rtems.org/rtems-libbsd/</a><br>
>> >> ><br>
>> >> > I suspect ppoll() might already be in there. Or at least supported by<br>
>> >> > FreeBSD.<br>
>> >> ><br>
>> >> > You should clone everything and grep the sources. newlib already has<br>
>> >> > qsort_r. This is the nm I used:<br>
>> >> ><br>
>> >> > $ ~/rtems-work/tools/6/bin/sparc-rtems6-nm ~/rtems-work/tools/6/sparc-rtems6/lib/libc.a | grep qsort_r<br>
>> >> > lib_a-bsd_qsort_r.o:<br>
>> >> > 00000000 T __bsd_qsort_r<br>
>> >> > lib_a-qsort_r.o:<br>
>> >> > 00000000 T qsort_r<br>
>> >> ><br>
>> >> > Notice the last line has "T qsort_r" which says it is defined.<br>
>> >> ><br>
>> >> > grep -r in the newlib source shows it is in ./libc/search/qsort_r.c<br>
>> >> ><br>
>> >> > dladdr() looks to be prototyped in RTEMS but hidden behind an ifdef like it<br>
>> >> > wasn't ported from NetBSD so that looks possible. It is in rtems.<br>
>> >> ><br>
>> >> > Those two examples should help you figure out why you missed<br>
>> >> > finding some things that were implemented.<br>
>> >> ><br>
>> >> > I need to figure out what this next POSIX version is to be called<br>
>> >> > so I can update the tracking spreadsheet that generates the RTEMS<br>
>> >> > POSIX Compliance Guide, :)<br>
>> >> ><br>
>> >> > --joel<br>
>> >> >><br>
>> >> >><br>
>> >> >> > Thanks again!<br>
>> >> >> ><br>
>> >> >> > Matt<br>
>> >> >> ><br>
>> >> >> > On Fri, Mar 19, 2021 at 1:58 PM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>> wrote:<br>
>> >> >> > ><br>
>> >> >> > > Keep devel@ on the list. :)<br>
>> >> >> > ><br>
>> >> >> > > On Fri, Mar 19, 2021 at 7:51 AM Matthew Joyce <<a href="mailto:mfjoyce2004@gmail.com" target="_blank">mfjoyce2004@gmail.com</a>> wrote:<br>
>> >> >> > >><br>
>> >> >> > >> Sir,<br>
>> >> >> > >><br>
>> >> >> > >> Thank you for the link! I see that you're right, those last four are<br>
>> >> >> > >> in newlib, plus memmem(). I updated those in the Google Sheet.<br>
>> >> >> > >><br>
>> >> >> > >> Now I see the newlib part, but where are you referring to specifically<br>
>> >> >> > >> when you say RTEMS, as in "POSIX support comes from a mix of RTEMS and<br>
>> >> >> > >> newlib"?<br>
>> >> >> > ><br>
>> >> >> > ><br>
>> >> >> > > POSIX is a HUGE HUGE standard and references other standards. One<br>
>> >> >> > > it references and pulls in is the C99 Standard C Library which is libc and<br>
>> >> >> > > libm. RTEMS mostly does not implement this functionality and relies on<br>
>> >> >> > > another open source project for those APIs. Newlib is an open source<br>
>> >> >> > > C Library used by RTEMS, Cygwin, and most embedded systems GNU tools<br>
>> >> >> > > chains.<br>
>> >> >> > ><br>
>> >> >> > > Most of the POSIX header files with RTEMS are actually in Newlib even<br>
>> >> >> > > if they originated with RTEMS. Many are shared with Cygwin.<br>
>> >> >> > ><br>
>> >> >> > > So methods like the string, memory, and *printf come from Newlib since they<br>
>> >> >> > > are in C99. We provide POSIX like threading, signals, core file access, and<br>
>> >> >> > > much more.<br>
>> >> >> > ><br>
>> >> >> > > It's a complementary relationship but it takes a bit to figure out when<br>
>> >> >> > > something should be in one or the other. The line gets blurred at times.<br>
>> >> >> > ><br>
>> >> >> > > Say you added a new CPU architecture implementation of a math<br>
>> >> >> > > method (like Eshan did last year), then it goes in newlib. But he also<br>
>> >> >> > > added some POSIX methods which go in RTEMS. In either case,<br>
>> >> >> > > we like tests for them in RTEMS to show they work in our environment.<br>
>> >> >> > ><br>
>> >> >> > > --joel<br>
>> >> >> > ><br>
>> >> >> > ><br>
>> >> >> > ><br>
>> >> >> > >><br>
>> >> >> > >> Thanks again!<br>
>> >> >> > >><br>
>> >> >> > >> Matt<br>
>> >> >> > >><br>
>> >> >> > >> On Fri, Mar 19, 2021 at 1:13 PM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>> wrote:<br>
>> >> >> > >> ><br>
>> >> >> > >> ><br>
>> >> >> > >> ><br>
>> >> >> > >> > On Fri, Mar 19, 2021, 6:40 AM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>> wrote:<br>
>> >> >> > >> >><br>
>> >> >> > >> >><br>
>> >> >> > >> >><br>
>> >> >> > >> >> On Fri, Mar 19, 2021, 5:48 AM Matthew Joyce <<a href="mailto:mfjoyce2004@gmail.com" target="_blank">mfjoyce2004@gmail.com</a>> wrote:<br>
>> >> >> > >> >>><br>
>> >> >> > >> >>> <a href="https://docs.google.com/spreadsheets/d/1reCNOIZC5JTwQENgl-hvG8THfQqNtlUDVy_07PYodic/edit?usp=sharing" rel="noreferrer" target="_blank">https://docs.google.com/spreadsheets/d/1reCNOIZC5JTwQENgl-hvG8THfQqNtlUDVy_07PYodic/edit?usp=sharing</a><br>
>> >> >> > >> >>><br>
>> >> >> > >> >>> Hello,<br>
>> >> >> > >> >>><br>
>> >> >> > >> >>> As suggested by Dr. Sherril, I've taken an initial look through this<br>
>> >> >> > >> >>> document <a href="https://www.opengroup.org/austin/docs/austin_1110.pdf" rel="noreferrer" target="_blank">https://www.opengroup.org/austin/docs/austin_1110.pdf</a> and<br>
>> >> >> > >> >>> added the new methods  to a Googe Sheet, linked above.<br>
>> >> >> > >> >>><br>
>> >> >> > >> >>> None of them appear to be in the RTEMS POSIX API Users Guide, but<br>
>> >> >> > >> >>> maybe that's not the right place to look. I'll stand by for your<br>
>> >> >> > >> >>> feedback regarding what's possible / desirable to add to RTEMS.<br>
>> >> >> > >> >><br>
>> >> >> > >> >><br>
>> >> >> > >> >> It is possible they are in our C Library or Math Library.  Or just not in the manual. The POSIX manual tends to be sparse since you can always use man pages or the POSIX standard.<br>
>> >> >> > >> >><br>
>> >> >> > >> >> Since you have RTEMS and tools built. Find one of the libc.a and libm.a files in the tools install and librtemscpu.a in the RTEMS build or install. Then try a command something like this:<br>
>> >> >> > >> >><br>
>> >> >> > >> >> CPU-rtems6-nm LIBRARY | grep SYMBOL<br>
>> >> >> > >> >><br>
>> >> >> > >> >> If you see it list with T then it is in the text section and there.<br>
>> >> >> > >> ><br>
>> >> >> > >> ><br>
>> >> >> > >> > Following up, I initially answered from my phone and didn't look at source.  I am still on my phone but looked through the list and think the last four methods are probably the only ones currently supported.<br>
>> >> >> > >> ><br>
>> >> >> > >> > <a href="https://sourceware.org/git/?p=newlib-cygwin.git;a=tree;f=newlib/libc/string;h=ceeec602cdd0e6b5c6b002b741bda9b41da4e441;hb=HEAD" rel="noreferrer" target="_blank">https://sourceware.org/git/?p=newlib-cygwin.git;a=tree;f=newlib/libc/string;h=ceeec602cdd0e6b5c6b002b741bda9b41da4e441;hb=HEAD</a><br>
>> >> >> > >> ><br>
>> >> >> > >> > POSIX support comes from a mix of RTEMS and newlib. That's key to this type of project.<br>
>> >> >> > >> ><br>
>> >> >> > >> > --joel<br>
>> >> >> > >> >><br>
>> >> >> > >> >><br>
>> >> >> > >> >><br>
>> >> >> > >> >>><br>
>> >> >> > >> >>> Thanks very much for your time!<br>
>> >> >> > >> >>><br>
>> >> >> > >> >>> Sincerely,<br>
>> >> >> > >> >>><br>
>> >> >> > >> >>> Matt<br>
>> >> >> > _______________________________________________<br>
>> >> >> > devel mailing list<br>
>> >> >> > <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
>> >> >> > <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</blockquote></div></div>