This is the mail archive of the mailing list for the newlib project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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?

> Do we want to keep the special cases for GO32 and __MSDOS__ on i386 or may I
> remove them and potentially break these targets?

Personally I would like to see them go rather sooner than later, but I
have no idea if we still have a consumer for them or not.  Jeff?


Corinna Vinschen
Cygwin Maintainer
Red Hat

Attachment: signature.asc
Description: PGP signature

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]