John, Jose,
I think it's very exciting that you're making libssh2 run also on
VMS! :)
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.
> > 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.
> No, that seems not a problem. The libssh2 developers have been very
> conservative or rather prudent. Writes are limited to 16k, in my
> experience, problems start to pop up when reads and writes get >
> 32k.
Using a buffer size in applications less than about 32500 bytes will
ensure correct operation with the latest few released versions of
libssh2. Unfortunately there are still known bugs in libssh2 when an
application likes to pass larger data buffers to the library.
In any case, libssh2 should handle short returns from send() and
recv() and ..
> Anyway, I have most examples working.
..if any example has a problem with buffer sizes then that is a bug
that we want to fix!
(Actually, any example not working is a bug we'd like to fix. :)
> > VMS also has problems with ".." in #include directives, and some
> > of the shared images only have uppercase universal symbols.
>
> No problems there either. libssh2 is only depending on OpenSSL (I
> use HP's, for convenience) , and zlib. Zlib on encompasserve seems
> like the way to go.
Note that zlib is an optional dependency. It's possible to build
libssh2 without zlib support, in which case no compression will be
negotiated with the SSH server.
> > Using the 'diff -u' option with exact case UNIX style path names
> > in quotes has been good enough for the projects that I have
> > worked on.
>
> That was also suggested by Thorvald. I like the idea of using git,
> though, as it might save me manual labour in the end.
>
> Question: should I do that against a current tarball or the latest
> stable release?
Please send git patches against the latest source possible, ideally
an up to date clone of libssh2.git, second best would be a snapshot
tarball which is sometimes identical to libssh2.git when there is
limited activity.
Worst case we could also accept a patch against latest release, but
this requires (sometimes substantial) work by developers for
integration, so it may lead to the integration being delayed, or just
never happen.
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
John E. Malmberg wrote:
>> I don't want libssh2 for the sake of curl
>
> It gives you a program that you can use to sanity check the build
> of libssh2 that the libssh2 developers are familiar with to answer
> questions.
Some developers, but not all. I consider it far more important to
reproduce any problems using one of the examples, or with a new
minimal C program that can be sent to the community for review and
further testing.
> 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.
> 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?
> 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.
//Peter
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2010-02-26