[lsb-discuss] LSB conf call notes for 2008-06-18

Jeff Licquia jeff at licquia.org
Wed Jun 18 09:08:44 PDT 2008

Attendees: Dan Kohn, Vojtech Pavlik, Stew Benedict, Mats Wichmann, Jeff 
Licquia, Robert Schweikert, Marvin Heffler, Alexey Khoroshilov, Ron 
Hale-Evans, Kay Tate, Ted Tso.

Some glitches found in the 3.2 release; please report any others to the 
list or IRC.

Working on new status table, at the top of ProjectPlan40 page on the 
wiki.  Not done yet, but people can take a look at it and add data they 
think might be missing.

gnu_get_libc_release.  Do we need it?  Robert: if it's LSB, then you 
shouldn't.  Jeff: some apps may dlopen() extra interfaces.  Kay: 
defensive purposes; guard against changes in glibc behavior.  Robert: 
who uses it?  Jeff: many different apps are in the Navigator.  Mats: 
apps trying to distinguish glibc behaviors; LSB reduces the need for 
that.  Dan: may be necessary as a migration aid, for vendors who have to 
support LSB and other situations.  Jeff: on all distros.  Ted: also, 
what if people implement the LSB using something besides glibc?  Mats: 
we can only document the form of the data, not its content.  Ted: can't 
really guarantee that the data returned is useful.

Jeff: heavy use by proprietary apps.  Mats: not surprising, given how 
easy it is to rebuild.  Kay: also, those apps may be more finely tuned. 
  Robert: thought they needed this to use an unstable interface, that 
had changed between glibc releases.  This put them outside the LSB, and 
not always helpful, as the interface can continue to change.

Ted: how harmful is the interface?  What's the cost?  Not very great. 
Jeff: research?  Ted: votes for adding it anyway, to remove any excuses. 
  Mats: maybe stall; is very easy to add later.  Other libcs don't 
emulate this.  Ted: would the added information change our decision or 
make it easier?

__getdelim.  Robert: avoid __ interfaces generally.  Jeff: policy 
decision, do we include __ when there's an optimization to be had?  Ted: 
do we know that this is just an optimization?  Jeff: bug seems to 
indicate that.  Really really really want.  Robert, Kay: how do you 
know?  Jeff: ISV demand, bug reports that things are slow that can be 
traced to this.  Ted: makes sense, probably want to add a note to the 
database about __getdelim and then wait for someone to express a need.

sendfile.  Talked about this before.  Jeff: summarize past discussions. 
  Seems like a slam-dunk to include; any objections?  Ted: man page is 
good, should use that.

epoll.  Seems to be consensus.  Disagree?  Mats: stable?  Ted: yes. 
Jeff: No objection; should go in.

remap_file_pages.  Jeff: bug says we need more input.  Robert: give 
people enough rope?  Mats: going down the road of "more Linux-specific"; 
if we're comfortable with that, then should be OK.  Ted: more of an 
efficiency gain; the same functionality can be had with mmap() as 
specified.  Jeff: some efficiency gain.  Ted: should be stable.  Jeff: 
tend to feel we should include these kinds of things.

getifaddrs.  Robert: ugly structure brought in.  Jeff: worried about 
IPv6 issues.  More research?  Mats: might be nice.  Ted: the 
functionality is needed.  Is there another way?  Mats: getaddrinfo? 
Jeff: doesn't provide the same information.  Ted: badly done, but legacy 
software uses this.  Leaning towards including it.  Mats: is there a 
correlation between these interfaces?  Would it buy us anything?  Are 
these the only interfaces that exclude apps?  Ted: probably should 
include it, but do the research also.

Mats: next three done already. (bugs 2153, 2154, 2155).  Can skip next time.

More information about the lsb-discuss mailing list