В Fri, 26 Feb 2010 14:20:29 +0000 (UTC) "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. OK, thank you all for the advices and active participation! I'll come back if there are any results. -- Alexander
Attachment:
signature.asc
Description: PGP signature