Subject: Re: Port to VMS; how to get changes into the main code stream?

Re: Port to VMS; how to get changes into the main code stream?

From: John E. Malmberg <wb8tyw_at_qsl.net>
Date: Fri, 26 Feb 2010 18:31:03 -0600

On 2/26/2010 10:36 AM, Peter Stuge wrote:
> Jose Baars wrote:
>> A test if a socket is blocking or non blocking in libssh2 is stack
>> specific I'm afraid.
>
> There are already various platform specific #ifdefs in
> get_socket_nonblocking() so I think adding a few more for complete
> support of TCP/IP options on VMS would not be a problem.

I would rather hide the sausage that goes into supporting multiple
TCP/IP stacks on VMS from the common code as much as possible.

Dynamically loading on VMS is best done with native OS calls, not dlload().

>>> The main issue that would likely to show up for libssh2 is that
>>> VMS has a limit on how much it can read/write to a socket in one
>>> operation.
>
> What is returned by send() or recv() when the limit is reached?
>
> libssh2 should not have a problem with send() or recv() returning
> short, meaning that not all of the desired bytes were accepted by the
> operating system.

The routines return the number of bytes transferred. As I recall the
limit is 65535 bytes.

The other thing I just remembered is that writev() and readv() on VMS
should be avoided. It may be better to trick configure that they are
not present. They have worse performance than just using read() and
write() multiple times.

>> Question: should I do that against a current tarball or the latest
>> stable release?

I mis-understood the original question as to doing the port, not
submitting the patches. Of course patches are best submitted against
the current tarball.

> Please try to send a git patch. If git doesn't work so well on VMS
> then perhaps one option could be to take advantage of git running on
> another system, in order to create the patch. Integration by libssh2
> developers is greatly simplified by having a clean patch as produced
> by git format-patch

That would be using NFS to share the file system. This is described in
the file unix_portability.pdf at ftp://encompasserve.org/gnv/

> John E. Malmberg wrote:

>> Linking against a specific TCP/IP stack should be avoided.
>
> I don't know the linker details on VMS, but if libraries are
> equivalent for all stacks and as long as there's a way to #ifdef the
> code that may be stack-specific then I don't think this should be
> neccessary.

A large subset of the libraries for each stack are equivalent and the C
runtime will dynamically load them to get this with out the programmer
having to know this. In the distant pass this was not the case, but
some programmers never updated their scripts, and others have copied
them, continuing a belief that there are differences in all cases. In
general when I update a port, one of the things that I do is remove that
unneeded complexity.

Each of the TCP/IP stacks does have some unique features that the C
library is not yet handling. But eventually they may achieve parity.

>> code to detect which TCP/IP stack is present and dynamically load
>> the right routine, or attempt to let the program know that the
>> feature is not present, if there is a way to work around it.
>
> Is the detection at compile time or must it be at run time?

Having the detection at run-time allows one binary to be distributed on
VMS. So only one package per CPU type instead of 3.

>> Configure runs very slowly on VMS, so those redundant tests hurt.
>
> If autotools (which produces the configure script) is awkward on VMS
> then I am all for adding "native" build files into libssh2 just like
> we have for Windows.

There are chicken and egg issues with getting autotools to work on VMS.
  I have most of the changes needed in the current shipping Perl, but
need to put in some fixes to the port of Bash, and then Perl will need
more changes.

Currently the work around is to have Linux NFS mount the VMS disk and
have it do the repository fetch and then generate the configure script.

But autotools is not the issue. The issue is simply that the tests
generated in configure are not really testing what they should be for
the most efficient code to be generated on a platform.

The best example is exit(). The GNV environment predefines a macro to
have exit() encode UNIX style exit status codes into the VMS standard
exit values.

That macro changes which link time symbol is used for exit() in the
header files.

With out the header files, exit() assumes that it is being passed a VMS
style exit code, except that it translates the 0 to the VMS status of 1.

So this means with out the hacks described on the Encompasserve.org
forums, configure will never see a test exit a code of 0.

The only way for configure to not require hacks on VMS is for it to do
the tests with the ANSI or X/OPEN headers first before probing for the
behavior with out headers. With out those header files, the routines
may have no UNIX/POSIX compatibility or have bugs in that compatibility
that existing programs depend on.

And I would not be surprised to find some *NIX systems out there with
the same issues where configure incorrectly diagnoses that a routine is
broken, where if it had used the header files, it would have obtained
the correct answer.

-John
wb8tyw_at_qsl.network
Personal Opinion Only
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2010-02-27