[lsb-discuss] LSB conf call notes for 2008-06-18
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