[lsb-discuss] LSB interface addition discussion

Wichmann, Mats D mats.d.wichmann at intel.com
Fri Jun 6 13:36:20 PDT 2008


On the theory that actual interface inclusion decisions
should be on a public mailing list, here are the pending
requests that have matching bugs.  I'd like to move
forward on deciding these pretty quickly so we can
wrap up the final details of the glibc-uplift-and-
addition work.

1664: ptrace
1739: dl_iterate_phdr
1751: dlinfo
1957: XextAddDisplay, XextFindDisplay, XextRemoveDisplay,
      XextCreateExtension, XextDestroyExtension,
      XextMissingExtension
1995: strverscmp
1997: alphasort, alphasort64, scandir, scandir64
2078: gnu_get_libc_release
2128: __getdelim (see general question below)
2133: sendfile, sendfile64
2137: epoll_create, epoll_ctl, epoll_wait
2142: remap_file_pages
2143: getifaddrs / freeifaddrs
2153: getservent_r, getservbyname_r, getservbyport_r
2154: getprotoent_r, getprotobyname_r, getprotobynumber_r
2155: hcreate_r, hdestroy_r, hsearch_r
2158: data (not functions) __progname_full, __progname,
      program_invocation_name, program_invocation_short_name
2161: getgrent_r, getpwent_r, fgetgrent, fgetpwent,
      fgetpwent_r, fgetgrent_r
2162: argz_add, argz_add_sep, argz_append, argz_count,
      argz_create, argz_create_sep, argz_delete, 
      argz_extract, argz_insert, argz_next, argz_replace,
      argz_stringify
2163: sysinfo, get_nprocs_conf, get_nprocs
2168: mempcpy, wmempcpy

Comment #1: none of these interfaces are in POSIX. This
does mean we would have to produce documentation (and, of
course tests).  also, any non-POSIX interface should be
considered for possible impacts on any non-glibc and/or
non-Linux situation, weighed against usefulness and how
widely used they are.  

Comment #2: I think the re-entrant set (2153, 2154, 2155
plus most of 2161) should be pretty non-controversial,
excepting the issue from #1.

Comment #3: as a general case, there are a LOT of interfaces
that begin with double underscores in glibc.  Many of these 
are not intended to be /directly/ called by applications, but
macros, optimizations, and other tricks may well cause them 
to appear in the compiled (non-LSB) binary.  In general we've
tried to keep these out of the API ("source standard") and
in some cases have had to bring them into the ABI ("binary
standard").  It's becoming hard to determine whether the
absence of these symbols is a problem or not; it does make
data analysis harder.  It's also a question of whether we
have some in that aren't needed.  2128, for example, brings
this issue forward.  We're looking for a discussion and
general decision on this.





More information about the lsb-discuss mailing list