Kernel-space ctypes.h support?

[Sebastian Huber]

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?

-- 
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.