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 jos...@codesourcery.com -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1002261403150.31...@digraph.polyomino.org.uk