The Linux Foundation

 
ISV Requested Interfaces

From The Linux Foundation

Revision as of 15:18, 28 January 2008 by Mats (Talk | contribs)

(diff) ←Older revision | view current revision (diff) | Newer revision→ (diff)

Contents

Interfaces Requested for LSB

To add a request, edit this page. It's useful to include a date. It's even more useful to make sure an application that uses the requested interface has been scanned and entered in the LSB Navigator.

Libraries

  • libGLU (07/09/07 -- Robert Schweikert)

At LSB F2F November 2007, it was decided that libGLU is a good candidate for LSB 4.0. Current import tools are not sufficient to reasonably import a C++ library, however a new tool is due.

Network interfaces

  • gethostbyaddr(_r)
  • gethostbyname(_r)
  • getserverbyname(_r)

These were once part of the LSB but were removed (most likely reason for deprecation of these interfaces is that these do not handle IPV6). One could write a compatibility library which re-defines these interfaces with an implementation based on getaddrinfo(). Applications requiring these interfaces could then ship the compatibility library. However, all Linux distributions have the symbols, thus a compatibility library would really be an ugly solution.

Update: gethostbyaddr, gethostbyname, getservbyname have always been in LSB. gethostbyaddr_r and gethostbyname_r are added for LSB 3.2. As part of a separate request, gethostbyname2 and gethostbyname2_r were also added for 3.2.

Not part of POSIX, thus it is not included in the LSB at this point. However, all Linux distributions have the symbol, thus inclusion should be possible. Update: added for 3.2.

  • getdtablesize

Workaround is possible by implementing a compatibility library which supplies a stub function to use sysconf(_SC_OPEN_MAX) (or alternatively, getrlimit with the RLIMIT_NOFILE option which amounts to the same thing) which can be shipped with any application. However, all Linux distributions have the symbol, thus a compatibility library would really be an ugly solution, and we'd have to maintain it. Further, such a compatibility library would likely grow to a whole bunch of hacks, better not to start.

Update: at LSB F2F November 2007, it was decided to "just add this one" (complete).

NIS interfaces

  • getdomainname

Not part of POSIX, thus it is not included in the LSB at this point. However, all Linux distributions have the symbol, thus inclusion should be possible.

Update: has been added for 3.2.

Memory interfaces

Notes from November 2007 F2F are italicized

  • mremap bug 1578. Added for 3.2.
  • mallinfo [1] [2] No, comments should be added to Navigator explaining why it's not there
  • mallopt [3] Probably 4.0 (due to resources)
  • malloc_trim [4] [5] Maybe, comments should be added to Navigator explaining why it's not there

File system interfaces

  • fstatfs(64)

At present LSB does not support a struct which allows the user to determine the file system on which a files resides.

Update: added for LSB 3.1 Update 1

Data exchange

  • xdrstdio_create

Update: added for LSB 3.2

HW topology

  • get_nprocs_conf

This is needed for parallel applications and applications using MPI. The HP MPI library uses this interface, others may as well. There is another approach using sysconf with _SC_NPROCESSORS_CONF and _SC_NPROCESSORS_ONLN.

At LSB F2F November 2007, probably need a bug, entry in database, more information before we act. Not in 3.2.

ChipHopper

The following are the interfaces used by multiple ISVs who have been through the IBM Chiphopper program offering.

  • Netgroups: endnetgrent, getnetgrent, innetgr, setnetgrent
  • Mount table interfaces: endmntent, getmntent, hasmntopt, setmntent
  • Mounting interfaces: mount, umount
  • rresvport - obtained privileged port, the rcmd* family is unacceptable these days so this won't be added
  • Streams interfaces - it's known on Linux these will return "no" (isastream) or ENOSYS (all the others). Given this, is there ANY value to including these stubs?

Update: mounting support has been discussed multiple times over the past seven years and mounting support is outside the scope of LSB at this time.

The netgroups question should be considered separately.

Other Comments

Falko Flessner (SAP):

- We'd like to see the libnuma/numactl as part of the standard where it makes sense - which is, by now, only x86_64. Itanium-NUMA is vendor-specific (i.e. SGIs Altix), so we can't expect the NUMA-Support to be available out-of-the-box.

John Dallman (UGS):

That makes excellent sense.

Falko Flessner (SAP):

- A SSL-Interface would be really great, but IIRC this is already planned, isn't it?

- The colleagues from the support-team like to see a debugger as part of the standard-installation. As this doesn't make sense for all installations, some kind of "supportability-package", inculding a debugger, strace, ldd... would be great. I'm sure some other ISVs like to see this, too.

John Dallman (UGS):

Indeed, we would. We've only worked with LSB on reasonably full-feature distributions (RHEL, SLES) where such things were available naturally, but having them available as part of the LSB would make life easier on less-comprehensive distros.

John Dallman (UGS):

I'm writing some test code for various run-time error handling. So I need to be able to generate floating-point errors and control how they're handled. The errors I want to generate and trap are divide-by-zero, overflow, and invalid operation, and I'm working on x86 and x86-64.

Generating the errors is quite easy with code, but persuading an LSB-built program to trap on them is more difficult. It doesn't seem to be possible to enable or disable specific floating-point traps with the C99 facilities that LSB supports. Or if it's possible, some indication of how would be very welcome!

I can enable traps easily with feenableexcept(), which is a GNU extension to C99, but if I do that, I have to link with cc, rather than lsbcc, to get the full GNU libm which supplies feenableecept(). So an LSB way of doing this would be good. If I use feenableecept(), I get SIGFPE generated without further difficulty, which is what I want.

Editorial: the set of functions in question is feenableexcept, fedisableexcept, fegetexcept. Notes from the November 2007 F2F... if we add mremap, and these three we can get the most "bang for our buck" and suddenly certify two applications

Update: these were tracked as bug 1767 and added for LSB 3.2.


[Article] [Discussion] [View source] [History]