IUCV is a hypervisor mediated communications method for z/VM guest virtual machines. Linux on z Systems (aka s390x) has supported this via the use of AF_IUCV sockets for many years (added to kernel Feb 2007). This suggested patch adds support to Python 2.7.9 for this socket type. I have built Python on both s390x and x86_64: both build cleanly and the test added to test_socket.py runs cleanly on s390x and is skipped on other platforms.

Hi,
First, please fill and submit a Contribution Agreement: https://www.python.org/psf/contrib/

Then about the patch:
- This is a patch against Python2.7, which is frozen for new developments. This change will only be applied to python 3.5 or later.
- There are some tab characters in the diff
- Names are limited to 8 characters, but there is no check.
- Names must be padded with spaces. This is done automatically in connect(), but these extra spaces should be removed in makesockaddr() so that the same names are returned.

Thanks. Question/responses in-line

On 4/1/15, 11:14 AM, "Amaury Forgeot d'Arc" <report@bugs.python.org> wrote:

>
>Amaury Forgeot d'Arc added the comment:
>
>Hi,
>First, please fill and submit a Contribution Agreement:
>https://www.python.org/psf/contrib/
Done but I never got the email confirmation - it was not in my spam fold
either.

>Then about the patch:
>- This is a patch against Python2.7, which is frozen for new
>developments. This change will only be applied to python 3.5 or later.
Understood.

>- There are some tab characters in the diff
Will fix

>- Names are limited to 8 characters, but there is no check.
I truncate, but I will add a check to be more programmer friendly

>- Names must be padded with spaces. This is done automatically in
>connect(), but these extra spaces should be removed in makesockaddr() so
>that the same names are returned.
Will do, I was going to let the caller strip() but I will do it here
instead. Is there an existing strip routine that I could call rather than
writing my own (trivial) stripper?

Do I resubmit the patch in the bug/enhancement report I had created?

Neale

The CA ack is a * added after your name here.  May take a week.
If you are asking whether to submit a new patch against 3.5, with suggested fixes, yes, please do
.

Updated patch
- Removes tabs
- Strips name/user/node returned by connect
- Checks lengths of name/user/node

Corrected a length error in the strip routine
Initialized the end of string indicator

Slavek, there's an s390x patch here to add AF_IUCV support to the socket module.

One interesting point to note is that s390x isn't an officially supported CPython architecture by the terms of PEP 11. While I can vouch for it working there (courtesy of beaker-project.org), I don't see any reasonable way we could provide an upstream buildbot for it.

I can provide one if required. I have access to an s390x Linux Foundation machine where I have a couple of virtual machines that could be used.

-------- Original message --------
From: Nick Coghlan <report@bugs.python.org>
Date:2015/04/02 06:35 (GMT-05:00)
To: Neale Ferguson <neale@sinenomine.net>
Subject: [issue23830] Add AF_IUCV support to sockets

Nick Coghlan added the comment:

Slavek, there's an s390x patch here to add AF_IUCV support to the socket module.

One interesting point to note is that s390x isn't an officially supported CPython architecture by the terms of PEP 11. While I can vouch for it working there (courtesy of beaker-project.org), I don't see any reasonable way we could provide an upstream buildbot for it.

----------
nosy: +bkabrda, ncoghlan

_______________________________________
Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue23830>
_______________________________________

The PyArg_ParseTuple() size arguments should be of type "Py_ssize_t" instead of "int".

Corrected declaration of args to PyArg_ParseTuple() from int to Py_ssize_t.

Attaching a patch based off 3.5.0a3.

Note, for Py_ssize_t I had to add:

#ifdef PY_SSIZE_T_CLEAN
        Py_ssize_t lNode, lUser, lName;
#else
        int lNode, lUser, lName;
#endif

As if I did not, the values I got back were garbage. Is this because of some configuration parameter I failed to use?

However, the patch builds on s390x and x86_64 and the test passes on the former and is skipped on the latter.

Removed two debug statements

Do you need any more information from me? As I said I may be able to provide a s390x buildbot slave if required. I have a CentOS 6.5 system on a linux foundation virtual machine that I can use for that purpose.

Updated patch against head (96580:3156dd82df2d). Built on s390x and x86_64. Test suite ran on both - tests successfully ignored on x86_64 and passed on s390x.