Re: [OMPI devel] OpenMPI not conforming with the C90 spec?

2006-08-19 Thread Adrian Knoth
On Thu, Aug 17, 2006 at 11:48:44PM +0100, Jonathan Underwood wrote:

> Hi,

Hi!

> Compiling a file with the gcc options -Wall and -pedantic gives the
> following warning:
> mpi.h:147: warning: ISO C90 does not support 'long long'
> Is this intentional, or is this a bug?

If you do not insist on using C90, you may compile with -std=c99
to get rid of this message ;)

I don't have the C90 (ANSI-C) at my fingertips, but I confirm it
does not support "long long".

Perhaps we should use int64_t instead.

-- 
mail: a...@thur.de  http://adi.thur.de  PGP: v2-key via keyserver

Scheiße wird nicht dadurch besser oder sicherer, dass man ein paar
Shareware-Warnlämpchen dranpappt. (Robin S. Socha über "Desktop-Firewalls")


[OMPI devel] A few notes on IPv6 status

2006-08-19 Thread Adrian Knoth
Hi,

as mentioned earlier this year, I'm now working on IPv6 support
for OpenMPI.

The main design goals are:

   - do not break existing IPv4 code
   - compile on SUSv2 (without new socket API)
   - do not use mapped addresses
   - test the new code on many systems

The porting of OPAL is more or less finished (at least on Linux, but
I'll do some investigations on *BSD and Solaris) and I've halfway
ported ORTE (perhaps I can manage it within the next two or three
weeks). I'll still have to write more test code, but that's already
scheduled for tomorrow.

Christian Kauhaus proposed to set up a blog containing news about
progress, early patches and so on. Is there anyone who'd like to
read it? ;)

I have a few questions to discuss:

 In opal/util/if.c:

/*
 *  Attempt to resolve the adddress as either a dotted decimal formated
 *  string or a hostname and lookup corresponding interface.
 */

int opal_ifaddrtoname(const char* if_addr, char* if_name, int length)


And somewhere below:

#define ADDRLEN 100
bool
opal_ifislocal(char *hostname)
{
char addrname[ADDRLEN + 1];
[..]
ret = opal_ifaddrtoname(hostname, addrname, ADDRLEN);

Why ADDRLEN? Shouldn't IF_NAMESIZE (defined 32) do the job?
opal_ifaddrtoname copies the interface name to its second
parameter (here: addrname), so the largest string can only
be as long as IF_NAMESIZE.

ORTE-question:

According to RFC 3986 (and some others), I've implemented the
service string as follows:

#ifdef IPV6
if (addr.sin6_family == AF_INET) {
ptr += sprintf(ptr, "tcp://%s:%d", opal_sockaddr2str(&addr),
  ntohs(mca_oob_tcp_component.tcp_listen_port));
}

if (addr.sin6_family == AF_INET6) {
ptr += sprintf(ptr, "tcp://[%s]:%d", opal_sockaddr2str(&addr),
ntohs(mca_oob_tcp_component.tcp_listen_port));
}
#else
ptr += sprintf(ptr, "tcp://%s:%d", inet_ntoa(addr.sin_addr),
  ntohs(mca_oob_tcp_component.tcp_listen_port));
#endif


Do you agree with a resulting URL like tcp://[2001:6f8::1]:port or
do you think it should be tcp6://?

I prefer the first one due to its RFC compliance. Both versions
won't interfear with existing libraries, because parse_uri would
return ORTE_ERR_BAD_PARAM in case of IPv6-connect strings on
ipv6-unaware systems.

Is it ok to use -DIPV6 or should I rename it? Is there already
a way to get the operating system we're compiling for? (uname -s)

IPv6 interface discovery (talking about opal/util/if.c again)
needs special treatment on some systems. Right now, I have
-DLINUX_IPV6 and I'd probably need to catch more (at least
HPUX defines SIOCGLIFADDR which is also present on OpenBSD).

If I'd have something like -DLINUX, I wouldn't need to
introduce more defines (like -DLINUX_IPV6 oder -DBSD_IPV6).

There is probably more to discuss (i.e. the CIDR support I've
implemented), but let's delay this until the first patch ;)


Best regards.

-- 
mail: a...@thur.de  http://adi.thur.de  PGP: v2-key via keyserver

Win95 Error 188: User hat sich aufgehängt