Re: [PATCH 09/22] Provide cap_rights_t via <sys/types.h>

[Sebastian Huber <sebastian dot huber at embedded-brains dot de>]

On 20/04/16 13:07, Corinna Vinschen wrote:
> On Apr 20 11:48, Sebastian Huber wrote:
> > >On 20/04/16 10:49, Corinna Vinschen wrote:
> > > > >Hi Sebastian,
> > > > >
> > > > >On Apr 18 15:29, Sebastian Huber wrote:
> > > > > >>Provide cap_rights_t via <sys/types.h> if __BSD_VISIBLE for BSD
> > > > > >>compatibility.
> > > > >Do we really want to clutter the namespace with all these very
> > > > >FreeBSD-centric types?  I'm mostly concerned about this struct
> > > > >cap_rights, but also many of the other types are rather... uncommon.
> > > > >I checked their existence on OpenBSD, NetBSD, and Linux, and none of
> > > > >them define those:
> > > > >
> > > > >   addr_t
> > > > >   accmode_t
> > > > >   cap_rights/cap_rights_t
> > > > >   c_caddr_t
> > > > >   cpulevel_t
> > > > >   cpusetid_t
> > > > >   cpuwhich_t
> > > > >   uintfptr_t
> > > > >   vm_offset_t
> > > > >   vm_size_t
> > > > >   vm_ooffset_t
> > > > >   vm_paddr_t
> > > > >   vm_pindex_t
> > > > >
> > > > >addr_t, vm_offset_t, and vm_size_t are defined in Cygwin, but still,
> > > > >do we really want them available generically?  __BSD_VISIBLE is set
> > > > >by default...
> > >
> > >For RTEMS we definitely want these types, since we want to use code from
> > >FreeBSD. So, the question is, do all Newlib users want to see these types?
> > >Your survey suggests a no.
> > >
> > >What about the following:
> > >
> > >As the last step of <sys/types.h> add an
> > >
> > >#include <machine/_user_types.h>
> > >
> > >so that a particular Newlib target is able to provide additional user types.
> > >
> > >Move  "winsup/cygwin/include/cygwin/types.h" to
> > >"winsup/cygwin/include/machine/_user_types.h". Plague only the RTEMS users
> > >with these FreeBSD types.
> That sounds like a plan but... wouldn't that be ideally the job of
> machine/types.h?  Now that the file has no other uses anymore we
> could resurrect it for just this purpose.  Given that the idea is
> to define user-visible types, that sounds like the right thing to do
> to me, rather than inventing YA filename.
>
> Yes, no?

Since this file is purely a Newlib speciality and no user should 
directly include this header file I think that an underscore file name 
is better. It makes searching easier, compared to yet another "types.h".

--
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@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschÃftliche Mitteilung im Sinne des EHUG.