[lsb-discuss] LSB interface addition discussion

Wichmann, Mats D mats.d.wichmann at intel.com
Mon Jun 9 08:22:25 PDT 2008


Robert Schweikert wrote:
> <snip>
> My comments:

Thanks for the comments!  I've interleaved some of mine
in several places.

>> 1664: ptrace
>> 
> Very useful

... but hard to implement, I believe

> Definitely needed
>> 1957: XextAddDisplay, XextFindDisplay, XextRemoveDisplay,
>>       XextCreateExtension, XextDestroyExtension,
>>       XextMissingExtension
>> 
> We should consider all missing Xext interfaces.

We're discussed this set many times before.  It turns up for
reasons that I don't think were anticipated (by the X developers),
there's no documentation and we have to also specify an internal
structure that the X developers in the past have stongly opposed
freezing in specification (as noted, they have not done so
themselves that I can see).

>> 1995: strverscmp
>> 
> Interestingly Google finds that we deprecated this interface in LSB
> 2.1.0. Is there an alternative interface? WHo is using the interface?

it never seemed terrribly useful, I guess...

>> 2078: gnu_get_libc_release
>> 
> Is this really needed? An LSB compliant app is more or less tied to a
> specific version of glibc.

I don't think these should go in either.

>> 2128: __getdelim (see general question below)
>> 
> Can we find better ways to deal with the double underscore symbols?

we've raised the question, I'm not clear that we have the
right "absolutely required" set...

>> 2163: sysinfo, get_nprocs_conf, get_nprocs
>>
> These should definitely be in the LSB

the latter two have another way to do the same through
sysconf so they seem a little unnecessary to me. We
could easily add a recommendation for sysconf
_SC_NPROCESSORS_ONLY and _SC_NPROCESSORS_CONF (actually 
the only user in Navigator is Intel Threading Blocks)

sysinfo is a different story.  I'd want to hear what the
kernel folks think of standardizing this one since it pulls
the structure definition from <linux/kernel.h>, not from a
regular glibc headers (the structure seems to have been
stable for a really long time, though, through the entire
2.4 and 2.6 kernel series, unless I read wrong).




More information about the lsb-discuss mailing list