Bug#570233: [patches] please add timepps.h

["Joseph S. Myers" <joseph@codesourcery.com>]

On Fri, 26 Feb 2010, Alexander Gordeev wrote:

> So, what's the decision?

EGLIBC only accepts patches that meet the legal requirements for inclusion 
in FSF GLIBC.  Thus, we cannot accept a new header without a copyright 
assignment to the FSF.  (It should also be formatted according to the GNU 
Coding Standards and use the same license as GLIBC - LGPL, not GPL.)

I would also suggest submitting such a new API for FSF GLIBC - although as 
there are no functions exported from the shared libraries, just inline 
functions, binary compatibility issues do not arise and so it is certainly 
possible in principle to add such APIs without them going in FSF GLIBC; 
there would be no need to disable them by default as described in 
<http://www.eglibc.org/archives/patches/msg00642.html>.

New interfaces certainly need documentation in the libc manual to be 
accepted by EGLIBC.  (Unfortunately, FSF GLIBC is laxer there and has 
added many functions without documentation.)

That said, I would question whether this is the right place for this 
interface - there are an enormous number of ioctls in the Linux kernel in 
support of different drivers, filesystems, etc., and I do not believe it 
is the place of libc to provide wrappers round all of them rather than 
just the basic ioctl function that other libraries can use to provide 
friendlier interfaces.  These functions do not seem to be closely 
entangled with the implementations of existing functions, or related to 
such functions.

And C library headers should provide a namespace-clean interface; they 
should not gratuitously include other headers that are only needed for the 
implementation, not the interface, and should only use symbols in the user 
namespace where strictly necessary as part of the interface.  (The user 
should be able to define arbitrary user-namespace identifiers - e.g. "ret" 
- as macros before including a header, except for those identifiers 
specifically documented as part of the interface to the header.)  This 
would tend to indicate that the right thing to do is to put these 
functions in the library, not inline in the header - so meaning that the 
ABI compatibility issues *do* arise.  Even if you provide a separate 
library, as I'd suggest, making the headers namespace-clean is still a 
good idea.

-- 
Joseph S. Myers
joseph@codesourcery.com