Implementing confstr()

[Joel Sherrill]

On Mon, Aug 7, 2017 at 5:35 PM, Chris Johns <chrisj at rtems.org> wrote:

> On 08/08/2017 00:38, Joel Sherrill wrote:
> > Hi
> >
> > Taking a private discussion public. Aditya is implementing the POSIX
> > method confstr() next. This email is my current set of thoughts on the
> > implementation of this method for RTEMS.
> >
> > First, I think confstr() belongs in the RTEMS source tree. It
> > is very similar to sysconf() but has to take the following "names" as
> > those to be able to retrieve:
> >
> > _CS_PATH
> > _CS_POSIX_V7_ILP32_OFF32_CFLAGS
> > _CS_POSIX_V7_ILP32_OFF32_LDFLAGS
> > _CS_POSIX_V7_ILP32_OFF32_LIBS
> > _CS_POSIX_V7_ILP32_OFFBIG_CFLAGS
> > _CS_POSIX_V7_ILP32_OFFBIG_LDFLAGS
> > _CS_POSIX_V7_ILP32_OFFBIG_LIBS
> > _CS_POSIX_V7_LP64_OFF64_CFLAGS
> > _CS_POSIX_V7_LP64_OFF64_LDFLAGS
> > _CS_POSIX_V7_LP64_OFF64_LIBS
> > _CS_POSIX_V7_LPBIG_OFFBIG_CFLAGS
> > _CS_POSIX_V7_LPBIG_OFFBIG_LDFLAGS
> > _CS_POSIX_V7_LPBIG_OFFBIG_LIBS
> > _CS_POSIX_V7_THREADS_CFLAGS
> > _CS_POSIX_V7_THREADS_LDFLAGS
> > _CS_POSIX_V7_WIDTH_RESTRICTED_ENVS
> > _CS_V7_ENV
> >
> > This is per http://pubs.opengroup.org/onlinepubs/9699919799/
> functions/confstr.html
> >
>
> Does the Open Group define the purpose for each of these values? It looks
> x86
> and Linux specific, ie how to build a 32bit app.
>

Agreed. I think we return an empty string for all of those but they were in
the POSIX standard. :(


>
> What is the purpose of 'POSIX_V7' in the label? I see FreeBSD 11.1 has
> '_CS_POSIX_V6_ILP32_OFF32_CFLAGS' etc and the Linux page you provided has
> '_CS_XBS5_ILP32_OFF32_CFLAGS' and I think glibc has 'POSIX_V7'.
>
>
V6 and V7 refer to the POSIX standard version. The rest if architecture
specific uselessness.


> Looking at the rationale and playing with the command on FreeBSD I see:
>
> $ command -p getconf _CS_PATH
> getconf: no such configuration parameter `_CS_PATH'
> $ command -p getconf PATH
> /usr/bin:/bin:/usr/sbin:/sbin
> $ command -p getconf POSIX_V6_LPBIG_OFFBIG_CFLAGS
> unsupported programming environment
> $ command -p getconf POSIX_V6_WIDTH_RESTRICTED_ENVS
> _POSIX_V6_LP64_OFF64
> $ command -p getconf _POSIX_V6_LP64_OFF64
>
>
>
>
> 1
>
> I find this a little confusing.
>
> > The value for those #define's should likely match what is in the Linux
> Software
> > Base: https://refspecs.linuxfoundation.org/LSB_1.2.0/gLSB.html That
> much goes
> > in newlib.
>
> For the numbering I see:
>
> $ uname
> FreeBSD
> $ grep -r _CS_PATH /usr/include/
> /usr/include/unistd.h:#define   _CS_PATH                1       /* default
> value
> of PATH */
>
> I would prefer we follow the FreeBSD lead here for numbering.
>
>
Doesn't matter to me.


> >
> > The confstr() implementation will be a switch on those values and
> > I honestly don't even know what most of those should be in an
> > RTEMS environment.
> >
> > But those are the names and we have to answer the question of what
> > is the appropriate value to return. A first implementation could return
> > something like getenv("PATH") for __CS_PATH, and take a swing at
> > the "obvious ones".
> >
> > The ones with CFLAGS, LDFLAGS, and LIBS would first have
> > to evaluated to see if the name makes sense to provide a value
> > for. And then return the value. I am tending to lean to returning
> > empty string for all of those.
> >
> > Looks like Linux doesn't support most of them:
> >
> > http://man7.org/linux/man-pages/man3/confstr.3.html
> >
> > I don't think this is a commonly used method so I would be perfectly
> > happy to support it in a minimal, but compliant manner.
> >
> > Any other thoughts?
> >
>
> If no one has a common set of names I wonder how it is to be managed in a
> portable way?
>

The names are consistent but vary based on the supported POSIX version.

Deciding on the set of names is definitely a Cygwin discussion.


>
> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20170807/3116a199/attachment-0002.html>