[lsb-discuss] Needed network interfaces

[Robert Schweikert]

On Tue, 2006-07-25 at 12:16 -0700, Nick Stoughton wrote:
> On Tue, 2006-07-25 at 14:35 -0400, Robert Schweikert wrote:
> > We are using the following network interfaces wjich are not part of the
> > LSB at this time. Any chance to get these added for 3.2?
> > 
> 
> Here's what the database says about these functions:
> +-----------------+-----------+--------------+
> | Iname           | Istatus   | Iwithdrawnin |
> +-----------------+-----------+--------------+
> | getdomainname   | Withdrawn | 3.0          |
> | gethostbyaddr_r | Excluded  | none         |
> | gethostbyname_r | Withdrawn | 3.0          |
> | getservbyname_r | Defered   | none         |
> | inet_aton       | Excluded  | none         |
> +-----------------+-----------+--------------+
> 
> 
> Note that two of them have been withdrawn ... they were marked as
> deprecated at 2.1 and removed from 3.0.
> 
> Getdomainname was dropped because it is an NIS interface, not in POSIX.
> We only had a handful of such interfaces, not the entire set, and they
> were all dropped. Getdomainname is NOT a network interface ... it is a
> NIS interface.

I understand the concern about getdomainname not being part of POSIX.
However, LSB is more than POSIX and NIS is part of glibc on every
distribution. If it were not, our application wouldn't work.

The NIS interfaces meet at least the "must be available on current
distributions criteria". Therefore, I think this should be revisited.

The problem here for the most part is licensing, and this will apply to
all proprietary applications using a license server. Almost all
applications use flexlm these days and it will be difficult at best to
get them to change their implementation and not use this interface.

> 
> The gethost* and getserv* interfaces are a little more problematic,
> since some of them are also in POSIX. I don't actually see a bug in
> bugzilla that explains why we deprecated and removed gethostbyname_r(),
> but you should note that a better, more generic, name server interface
> does exist: getaddrinfo(), and developers really should be trying to use
> that instead. BUT, the LSB is not a source standard, its an ABI, so
> perhaps we should revisit this earlier decision.

My comment about licensing applies here as well. If this were in house
code replacing the calls with getaddrinfo would certainly not be an
issue. 

I can also provide an interface library which exposes gethost* and
getserv* but calls getaddrinfo() under the covers. However, since these
are part of POSIX getting these back into LSB would be great.

> 
> NOTE also the gethost* and getserv* interfaces are IPv4 specific, while
> getaddrinfo also works with IPv6. POSIX may well deprecate the gethost*
> and getserv* interfaces during its current revision.

Oh yes the dream about IPv6..... I bet that our customers will not
switch to IPv6 within the next 5 years.

> 
> inet_aton has always been excluded because:
> a. It isn't in POSIX
> b. No apps seemed to need it (clearly this one is wrong!!!)
> c. We didn't have good text to describe it.
> d. We had no test to test it.

Again I understand the concern about inet_aton not being in POSIX.
However, the substitute call (inet_addr) is according to the man page
obsolete, and I'd hate to ask people to use interfaces which are marked
as obsolete in the man page. Here is the relevant snippet:

<snip>
The  inet_addr()  function  converts  the Internet host address cp from
numbers-and-dots notation into binary data in network byte  order.   If
the input is invalid, INADDR_NONE (usually -1) is returned.  This is an
obsolete interface to inet_aton, described  immediately  above;  it  is
obsolete because -1 is a valid address (255.255.255.255), and inet_aton
provides a cleaner way to indicate error return.
<snip>

> 
> It could go on the candidate list, if we abandon the promise made about
> never adding new interfaces at a minor revision unless it was obvious it
> was just one we forgot!
> 
-- 
Robert Schweikert                   MAY THE SOURCE BE WITH YOU
(Robert.Schweikert at abaqus.com)                 LINUX
ABAQUS Inc.
Phone : 401-276-7190
FAX : 401-276-4408