Date: Wed, 3 Jun 2020 22:35:11 -0700 From: Siva Chandra <sivachandra@...gle.com> To: libc-coord@...ts.openwall.com Cc: Petr Hosek <phosek@...gle.com> Subject: Re: Macro-based advertisement of libc extensions We (LLVM libc developers) are interested in this general topic as we are considering adding extensions to LLVM libc around the mutex types from the C standard header threads.h. Before I go into the details of what exactly we want to add, I have some inline comments on the main proposal in this thread. On Wed, Apr 22, 2020 at 10:38 AM Rich Felker <dalias@...c.org> wrote: > > This is proposal I've mentioned in various settings for a while, but > that should be discussed more thoroughly in a proper setting, and > libc-coord is the setting I'd been looking to do it in. > > > Proposal: > > I want to establish a common convention, with participation by > multiple (Linux and non-Linux, ideally BSDs and others too) libc > implementations, for macros defined by the implementation to advertise > nonstandard extensions offered for use by applications. > > These should be modeled on the POSIX macros defined in unistd.h, like > _POSIX_MONOTONIC_CLOCK, _POSIX_TIMERS, _POSIX_SEMAPHORES, etc. and > should use a dedicated part of the reserved namespace like _EXT_* or > similar. Possibly this should include the semantics for definition > with a value of 0 ("supported for compilation and might or might not > be supported at runtime"), which may make sense for implementations > with different profiles or that only offer certain functionality > contingent on a kernel that supports it, etc. If that option is taken, > there could be corresponding sysconf (e.g. _SC_EXT_*) macros to query > availability at runtime, or a separate interface so as not to overload > sysconf. Unless there is benefit in overloading existing conventions and naming schemes, I would prefer having a new naming scheme which reflects the fact that it has been added after sign-off on the libc-coord list. Perhaps something like _COORD_<...> which reflects that it has been signed-off by libc-coord while not being any more verbose than _POSIX_<...>. > Implementation: > > I'm not particular about how this is done, but my leaning would be > either putting the macros in an existing standard header (preference: > unistd.h) or defining a single macro via a standard header that > advertises the presence of a second header they're all provided by. > Another option might be grouping them by functionality (i.e. stdio > extensions are advertised in stdio.h). I prefer the latter option of grouping them by functionality. > Open questons: > > What degree of compatibility do "equivalent" extensions need to be > advertised as the same? While I'd like part of the outcome of this > effort to be standardization of common extensions that are deemed to > be worth standardization (upstreaming in C or POSIX), I'm not > proposing running a parallel extra-standard standards organization. I would view this as an arrangement of convenience and not as an extra-standard effort/organization. For one, this effort can serve as a staging area for proposals to the official standards' committees. Also, maintainers of different libcs can sign-off on a certain extension, but can choose not to provide that extension in their libc. They would of course have to sign-off on what exactly a certain extension is. > For extensions which already have multiple implementations, I think > the baseline macro should roughly mean "whatever is common between > historical implementations". If some implementations have additional > features (for example, accepting a null pointer) they can define in > addition to _EXT_FOO macros that advertise these additional properties > (in that example, _EXT_FOO_ACCEPTS_NULL). I would expect that all libcs have to agree on the set of extension macros. For example, if we libc-coord signs off only about the _EXT_FOO macro, but some libc provides _EXT_FOO_ACCEPTS_NULL without a sign-off from libc-coord, then that should amount to name pollution. So yes, all the extensions we accept/sign-off on have to be published and specified just like a formal standard would do. Requiring a precise specification might seem like a hard barrier, but without it, different libcs can potentially end up with differing semantics. > Where should common names be published? Maybe a libc-coord github project? > A minimal version of that would just be posting > intent to this list and not having sustained well-motivated objection > to it. But maybe something more official/searchable/etc. makes sense. A github project would give us a formal way of doing all of these. Coming back to mutex related extensions we would like to add to LLVM-libc: The standard specifies just one type mtx_t for recursive as well as non-recursive mutexes. We have observed that this leads to non-trivial costs in certain applications which only need non-recursive mutexes (because of the additional branches in the locking/unlocking functions). So, we would like to add two separate mutex types, one for non-recursive mutexes, and another for recursive mutexes. It seems a little premature to make a formal proposal about this as we are still discussing how to make proposals and add extensions. But, roughly, we would like the extension to be modelled like the C++ std::mutex and std::recursive_mutex classes (and may be even std::timed_mutex and friends.) Thanks, Siva Chandra
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.