[PATCH 09/22] Provide cap_rights_t via <sys/types.h>
Corinna Vinschen
vinschen@redhat.com
Wed Apr 20 13:54:00 GMT 2016
On Apr 20 13:12, Sebastian Huber wrote:
>
>
> 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".
I disagree. There's no _user_types.h anywhere but lots of types.h
in various subdirs. I think the machine-specific extention to
sys/types.h should called machine/types.h. That's least surprising
and easy to find.
Corinna
--
Corinna Vinschen
Cygwin Maintainer
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20160420/a52cbe0f/attachment.sig>
More information about the Newlib
mailing list