Kernel-space ctypes.h support?

Fri Sep 14 16:57:14 UTC 2018

On Fri, Sep 14, 2018 at 12:57 AM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> On 14/09/2018 04:27, Joel Sherrill wrote:
> >
> >
> > On Thu, Sep 13, 2018, 9:25 PM Chris Johns <chrisj at rtems.org
> > <mailto:chrisj at rtems.org>> wrote:
> >
> >     On 14/09/2018 10:13, Joel Sherrill wrote:
> >     > On Thu, Sep 13, 2018, 5:40 PM Chris Johns <chrisj at rtems.org
> >     <mailto:chrisj at rtems.org>
> >     > <mailto:chrisj at rtems.org <mailto:chrisj at rtems.org>>> wrote:
> >     >     On 14/09/2018 02:30, Joel Sherrill wrote:
> >     >     > On Thu, Sep 13, 2018, 10:34 AM Sebastian Huber
> >     >     > <sebastian.huber at embedded-brains.de
> >     <mailto:sebastian.huber at embedded-brains.de>
> >     >     <mailto:sebastian.huber at embedded-brains.de
> >     <mailto:sebastian.huber at embedded-brains.de>>
> >     >     <mailto:sebastian.huber at embedded-brains.de
> >     <mailto:sebastian.huber at embedded-brains.de>
> >     >     <mailto:sebastian.huber at embedded-brains.de
> >     <mailto:sebastian.huber at embedded-brains.de>>>>
> >     >     > wrote:
> >     >     >     ----- Am 13. Sep 2018 um 14:07 schrieb joel
> >     joel at rtems.org <mailto:joel at rtems.org>
> >     >     <mailto:joel at rtems.org <mailto:joel at rtems.org>>
> >     >     >     <mailto:joel at rtems.org <mailto:joel at rtems.org>
> >     <mailto:joel at rtems.org <mailto:joel at rtems.org>>>:
> >     >     >
> >     >     >     > On Thu, Sep 13, 2018, 3:28 AM Sebastian Huber <
> >     >     >     > sebastian.huber at embedded-brains.de
> >     <mailto:sebastian.huber at embedded-brains.de>
> >     >     <mailto:sebastian.huber at embedded-brains.de
> >     <mailto:sebastian.huber at embedded-brains.de>>
> >     >     >     <mailto:sebastian.huber at embedded-brains.de
> >     <mailto:sebastian.huber at embedded-brains.de>
> >     >     <mailto:sebastian.huber at embedded-brains.de
> >     <mailto:sebastian.huber at embedded-brains.de>>>> wrote:
> >     >     >     >
> >     >     >     >> Hello,
> >     >     >     >>
> >     >     >     >> I test currently the tqm8xx BSP which worked fine
> >     until RTEMS 5. The
> >     >     >     >> problem is that this BSP uses strtoul() to get some
> >     system
> >     >     configuration
> >     >     >     >> parameters from the boot loader. The Newlib used by
> >     RTEMS 5 has now
> >     >     >     >> support for C locales in strtoul(). The C locale
> >     support needs an
> >     >     >     >> executing thread with a valid Newlib reentrancy
> >     structure. This is
> >     >     >     >> definitely not the case during bsp_start().
> >     >     >     >>
> >     >     >     >
> >     >     >     > Why do we now longer have a global reentrancy
> >     structure to fall back on?
> >     >     >
> >     >     >     I think having a global reentrancy as a fall back just
> >     for the lowest
> >     >     level
> >     >     >     system start without an idle thread is a bit of overkill.
> >     >     >
> >     >     >     The heavy weight C local support which was recently
> >     introduced in
> >     >     Newlib is
> >     >     >     not really the right thing for the embedded systems I
> >     know.  There were
> >     >     >     several complaints about this on the Newlib mailing
> >     list as well.  The
> >     >     root
> >     >     >     cause for this is the C standard. So, basically the C
> >     standard
> >     >     strtoul() is
> >     >     >     unsuitable for embedded systems. The FreeBSD
> >     (sys/kern/strtoul.c) and
> >     >     Linux
> >     >     >     (lib/kstrtox.c) kernel have their own implementations.
> >     >     >
> >     >     >
> >     >     > FWIW the FACE Technical Standard does not include wide
> >     characters in ANY
> >     >     profile
> >     >     > as of Edition 3.0. None of the RTOS vendors knew of any
> >     avionics users. It
> >     >     > wasn't viewed as a necessary feature. We could consider
> >     disabling it by
> >     >     default.
> >     >     >
> >     >
> >     >     Is this something we could ot would want to control with
> >     newlib via a config
> >     >     option?
> >     >
> >     >
> >     > We don't turn on locale for h8, m32c and maybe not epiphany. I
> >     am pretty sure.it <http://sure.it>
> >     > <http://sure.it> is an option. And should be a documented RSB
> >     option to turn it
> >     > back on. Should be a size savings for most users.
> >
> >     We turn on or off as an option?
> >
> >
> > Based on Sebastian's observation, I think off.
> >
> > Does this impact wide characters and multibyte?
> >
> > We will need to document the impact. I suspect it removes some POSIX
> > support in a base build.
>
> This problem with the C locale support used in strtoul() has absolutely
> nothing to do with the wide character or iconv() support.
>
> Currently it is not possible to disable the C locale support in Newlib.
> Would such an option be the preferred way instead of a custom strtoul()
> etc. API and implementation?
>

I think so. It would result in smaller footprint which is desirable for an
unlikely to be used feature.

I would like to know the impact of only having a single default locale
though.

>
> --
> 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.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180914/2e800dee/attachment-0002.html>