Re: [systemd-devel] [PATCH 2/2] udev/path_id: improve and enhance bus detection for Linux on z Systems
Hi folks, On Wed, Sep 23, 2015 at 01:42:57PM +0200, Hendrik Brueckner wrote: > From: Liu Yuan Yuan <bjyy...@linux.vnet.ibm.com> > > Improve and enhance the path_id udev builtin to correctly handle bus' > available on Linux on z Systems (s390). > > Previously, the CCW bus and, in particular, any FCP devices on it, have > been treated separately. This commit integrates the CCW bus into the > device chain loop. FCP devices and their associated SCSI disks are now > handled through the common SCSI handling functions in path_id. > > This implies also a change in the naming of the symbolic links created > by udev. So any backports of this commit to existing Linux distribution > must be done with care. If a backport is requires, a udev rule can be > created to create the "old-style" symbolic links too. > > Apart from the CCW bus, this commit adds bus support for the: > > - ccwgroup bus which manages network devices, and > - ap bus which manages cryptographic adapters > - iucv bus which manages IUCV devices on z/VM > > Signed-off-by: Liu Yuan Yuan <bjyy...@linux.vnet.ibm.com> > Signed-off-by: Hendrik Brueckner <brueck...@linux.vnet.ibm.com> > --- > src/udev/udev-builtin-path_id.c | 57 -- > 1 files changed, 30 insertions(+), 27 deletions(-) Any feedback regarding this change? Did I miss to notify someone to pick that patch up? Thanks and kind regards, Hendrik ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] s390: add personality support
Introduce personality support for Linux on z Systems to run
particular services with a 64-bit or 31-bit personality.
---
Makefile.am|1 +
src/basic/util.c | 27 +++
src/test/test-execute.c|8 ++--
test/exec-personality-s390.service |7 +++
4 files changed, 41 insertions(+), 2 deletions(-)
create mode 100644 test/exec-personality-s390.service
diff --git a/Makefile.am b/Makefile.am
index 41bfdfb..e9ad723 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1502,6 +1502,7 @@ EXTRA_DIST += \
test/exec-ignoresigpipe-yes.service \
test/exec-personality-x86-64.service \
test/exec-personality-x86.service \
+ test/exec-personality-s390.service \
test/exec-privatedevices-no.service \
test/exec-privatedevices-yes.service \
test/exec-privatetmp-no.service \
diff --git a/src/basic/util.c b/src/basic/util.c
index 18be0bf..40a4b8f 100644
--- a/src/basic/util.c
+++ b/src/basic/util.c
@@ -5261,6 +5261,19 @@ unsigned long personality_from_string(const char *p) {
if (streq(p, "x86"))
return PER_LINUX;
+
+#elif defined(__s390x__)
+
+if (streq(p, "s390"))
+return PER_LINUX32;
+
+if (streq(p, "s390x"))
+return PER_LINUX;
+
+#elif defined(__s390__)
+
+if (streq(p, "s390"))
+return PER_LINUX;
#endif
return PERSONALITY_INVALID;
@@ -5280,6 +5293,20 @@ const char* personality_to_string(unsigned long p) {
if (p == PER_LINUX)
return "x86";
+
+#elif defined(__s390x__)
+
+if (p == PER_LINUX)
+return "s390x";
+
+if (p == PER_LINUX32)
+return "s390";
+
+#elif defined(__s390__)
+
+if (p == PER_LINUX)
+return "s390";
+
#endif
return NULL;
diff --git a/src/test/test-execute.c b/src/test/test-execute.c
index dd8ab7d..fa6336f 100644
--- a/src/test/test-execute.c
+++ b/src/test/test-execute.c
@@ -77,10 +77,14 @@ static void test_exec_workingdirectory(Manager *m) {
}
static void test_exec_personality(Manager *m) {
-test(m, "exec-personality-x86.service", 0, CLD_EXITED);
-
#if defined(__x86_64__)
test(m, "exec-personality-x86-64.service", 0, CLD_EXITED);
+
+#elif defined(__s390__)
+test(m, "exec-personality-s390.service", 0, CLD_EXITED);
+
+#else
+test(m, "exec-personality-x86.service", 0, CLD_EXITED);
#endif
}
diff --git a/test/exec-personality-s390.service
b/test/exec-personality-s390.service
new file mode 100644
index 000..f3c3b03
--- /dev/null
+++ b/test/exec-personality-s390.service
@@ -0,0 +1,7 @@
+[Unit]
+Description=Test for Personality=s390
+
+[Service]
+ExecStart=/bin/sh -c 'echo $(uname -m); exit $(test $(uname -m) = "s390")'
+Type=oneshot
+Personality=s390
--
1.7.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] udev/path_id: improve and enhance bus detection for Linux on z Systems
From: Liu Yuan Yuan <bjyy...@linux.vnet.ibm.com>
Improve and enhance the path_id udev builtin to correctly handle bus'
available on Linux on z Systems (s390).
Previously, the CCW bus and, in particular, any FCP devices on it, have
been treated separately. This commit integrates the CCW bus into the
device chain loop. FCP devices and their associated SCSI disks are now
handled through the common SCSI handling functions in path_id.
This implies also a change in the naming of the symbolic links created
by udev. So any backports of this commit to existing Linux distribution
must be done with care. If a backport is requires, a udev rule can be
created to create the "old-style" symbolic links too.
Apart from the CCW bus, this commit adds bus support for the:
- ccwgroup bus which manages network devices, and
- ap bus which manages cryptographic adapters
- iucv bus which manages IUCV devices on z/VM
Signed-off-by: Liu Yuan Yuan <bjyy...@linux.vnet.ibm.com>
Signed-off-by: Hendrik Brueckner <brueck...@linux.vnet.ibm.com>
---
src/udev/udev-builtin-path_id.c | 57 --
1 files changed, 30 insertions(+), 27 deletions(-)
diff --git a/src/udev/udev-builtin-path_id.c b/src/udev/udev-builtin-path_id.c
index 01e2c65..a436e4f 100644
--- a/src/udev/udev-builtin-path_id.c
+++ b/src/udev/udev-builtin-path_id.c
@@ -591,31 +591,23 @@ static struct udev_device *handle_bcma(struct udev_device
*parent, char **path)
return parent;
}
-static struct udev_device *handle_ccw(struct udev_device *parent, struct
udev_device *dev, char **path) {
-struct udev_device *scsi_dev;
+/* Handle devices of AP bus in System z platform. */
+static struct udev_device *handle_ap(struct udev_device *parent, char **path) {
+const char *type, *func;
assert(parent);
-assert(dev);
assert(path);
-scsi_dev = udev_device_get_parent_with_subsystem_devtype(dev, "scsi",
"scsi_device");
-if (scsi_dev != NULL) {
-const char *wwpn;
-const char *lun;
-const char *hba_id;
-
-hba_id = udev_device_get_sysattr_value(scsi_dev, "hba_id");
-wwpn = udev_device_get_sysattr_value(scsi_dev, "wwpn");
-lun = udev_device_get_sysattr_value(scsi_dev, "fcp_lun");
-if (hba_id != NULL && lun != NULL && wwpn != NULL) {
-path_prepend(path, "ccw-%s-zfcp-%s:%s", hba_id, wwpn,
lun);
-goto out;
-}
-}
+type = udev_device_get_sysattr_value(parent, "type");
+func = udev_device_get_sysattr_value(parent, "ap_functions");
-path_prepend(path, "ccw-%s", udev_device_get_sysname(parent));
+if (type != NULL && func != NULL) {
+path_prepend(path, "ap-%s-%s", type, func);
+goto out;
+}
+path_prepend(path, "ap-%s", udev_device_get_sysname(parent));
out:
-parent = skip_subsystem(parent, "ccw");
+parent = skip_subsystem(parent, "ap");
return parent;
}
@@ -627,13 +619,6 @@ static int builtin_path_id(struct udev_device *dev, int
argc, char *argv[], bool
assert(dev);
-/* S390 ccw bus */
-parent = udev_device_get_parent_with_subsystem_devtype(dev, "ccw",
NULL);
-if (parent != NULL) {
-handle_ccw(parent, dev, );
-goto out;
-}
-
/* walk up the chain of devices and compose path */
parent = dev;
while (parent != NULL) {
@@ -681,6 +666,25 @@ static int builtin_path_id(struct udev_device *dev, int
argc, char *argv[], bool
parent = skip_subsystem(parent, "scm");
supported_transport = true;
supported_parent = true;
+} else if (streq(subsys, "ccw")) {
+path_prepend(, "ccw-%s",
udev_device_get_sysname(parent));
+parent = skip_subsystem(parent, "ccw");
+supported_transport = true;
+supported_parent = true;
+} else if (streq(subsys, "ccwgroup")) {
+path_prepend(, "ccwgroup-%s",
udev_device_get_sysname(parent));
+parent = skip_subsystem(parent, "ccwgroup");
+supported_transport = true;
+supported_parent = true;
+} else if (streq(subsys, "ap")) {
+parent = handle_ap(parent, );
+supported_transport = true;
+supported_parent = true;
+} else if
Re: [systemd-devel] [PATCH] s390/getty-generator: initialize essential system terminals/consoles
On Tue, Feb 04, 2014 at 05:06:57PM +0100, Dr. Werner Fink wrote: On Tue, Feb 04, 2014 at 02:25:06PM +0100, Lennart Poettering wrote: On Mon, 03.02.14 14:44, Hannes Reinecke (h...@suse.de) wrote: Which raises the question: what exactly should be 'active' contain? The console name (which doesn't have any equivalent in sysfs), or the tty name (which has)? Userspace expects that /sys/class/tty/console/active refers to a valid tty name, and that /sys/class/tty/tty0/active refers to a valid VT tty name. Even if the identifier string of tty3270.c becomes 3270/tty it seems that something goes wrong as in show_cons_active() of drivers/tty/tty_io.c the name_base of the struct tty_driver is not honored. Also on s390 the device for 3270/tty its self is not plugged: systemctl list-units | grep virtual-tty | sed 's/^/ /' sys-devices-virtual-tty-hvc0.device loaded active plugged /sys/devices/virtual/tty/hvc0 sys-devices-virtual-tty-hvc1.device loaded active plugged /sys/devices/virtual/tty/hvc1 sys-devices-virtual-tty-hvc2.device loaded active plugged /sys/devices/virtual/tty/hvc2 sys-devices-virtual-tty-hvc3.device loaded active plugged /sys/devices/virtual/tty/hvc3 sys-devices-virtual-tty-hvc4.device loaded active plugged /sys/devices/virtual/tty/hvc4 sys-devices-virtual-tty-hvc5.device loaded active plugged /sys/devices/virtual/tty/hvc5 sys-devices-virtual-tty-hvc6.device loaded active plugged /sys/devices/virtual/tty/hvc6 sys-devices-virtual-tty-hvc7.device loaded active plugged /sys/devices/virtual/tty/hvc7 sys-devices-virtual-tty-ttysclp0.device loaded active plugged /sys/devices/virtual/tty/ttysclp0 as the existing directory /sys/devices/virtual/tty/3270!tty1 is not listed at least with 208. Nevertheless the nodes are there The 3270 devices should be tagged for systemd in the 99-systemd.rules file. ll /dev/3270/tty1 crw--w 1 root tty 227, 1 Feb 4 15:51 /dev/3270/tty1 but a `dev-3270-tty1.device' seems not to be usable. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] s390/getty-generator: initialize essential system terminals/consoles
On Mon, Feb 03, 2014 at 02:44:43PM +0100, Hannes Reinecke wrote: On 01/31/2014 05:08 PM, Hendrik Brueckner wrote: Ensure to start getty programs on all essential system consoles on Linux on System z. Add these essential devices to the list of virtualization_consoles to always generate getty configurations. For the sake of completion, the list of essential consoles is: /dev/sclp_line0 - Operating system messages applet (LPAR) /dev/ttysclp0 - Integrated ASCII console applet (z/VM and LPAR) /dev/ttyS0 - Already handled by systemd (3215 console on z/VM) /dev/hvc0 - Already handled by systemd (IUCV HVC terminal on z/VM) Depending on the environment, z/VM or LPAR, only a subset of these terminals are available. See also RH BZ 860158[1] Cannot login via Operating System Console into RHEL7 instance installed on a LPAR. This bugzilla actually blocks the installation of Linux on System z instances in LPAR mode. Hehe. Nice try, but sadly incomplete. When switching to a real 3270 console (try 'conmode=3270' on the kernel command line) systemd isn't able to open a console, either. You are right. This change is incomplete regarding support for the 3270 terminals. Which opens up a can of worms: - The S/390 3270 tty device is using a device node /dev/3270/ttyX _and_ an offset '1' to the minor node. So the first tty here is in fact /dev/3270/tty1 So this requires yet another entry to the systemd rules file to tag 3270 terminal devices. - systemd is using the 'active' sysfs attribute in /sys/class/tty/console to figure out the active console; for the 3270 console this contains the string 'tty32700'. Which of course doesn't exist and confuses systemd getty-generator. The reason for the slightly weird string in 'active' is the way it's generated (check drivers/tty/tty_io.c:show_cons_active()): count += sprintf(buf + count, %s%d%c, cs[i]-name, cs[i]-index, i ? ' ':'\n'); where 'cs' is the _console_ structure, not the tty structure. So we're getting the _console_ name plus the _console_ index here. And the console name for the 3270 console is 'tty3270', with the index '0'. From the source code this simply states the name of the console device. The console device is not say *anything* about a potential associated terminal device. Console names (console= kernel parameter) are just identifiers. Which raises the question: what exactly should be 'active' contain? The console name (which doesn't have any equivalent in sysfs), or the tty name (which has)? And, more importantly, how is one supposed to _find_ the corresponding sysfs entry for the current 'active' attribute? Perhaps it's time for a new sysfs attribute to display the associated terminal device (if any). From what I've seen most driver work by virtue of the happy accident that the console index equals the tty index. This is just naming... you can also develop a console without any terminal device involved. But that's not a requirement anywhere in the console code. Quite the contrary; tty drivers have the 'first_minor' entry to explicit request an offset other than '0'. (And the console driver has an explict '-device' callback which allows the tty driver to return the correct index. Not that it's used here; would've been too easy). So how to fix this? Update the driver to adhere to the (broken) current behaviour? Or modify 'active' to return the corrent tty name? That's probably a good option but might break existing applications that rely on what is in active. Alternatively add a new sysfs attribute to display console's associated terminal devices. ... or don't look at the console at all and start getty's on those terminal devices that are available. Or add a workaround to systemd? Kind regards, Hendrik ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] s390/getty-generator: initialize essential system terminals/consoles
Ensure to start getty programs on all essential system consoles on Linux on
System z. Add these essential devices to the list of virtualization_consoles
to always generate getty configurations.
For the sake of completion, the list of essential consoles is:
/dev/sclp_line0 - Operating system messages applet (LPAR)
/dev/ttysclp0 - Integrated ASCII console applet (z/VM and LPAR)
/dev/ttyS0 - Already handled by systemd (3215 console on z/VM)
/dev/hvc0 - Already handled by systemd (IUCV HVC terminal on z/VM)
Depending on the environment, z/VM or LPAR, only a subset of these terminals
are available.
See also RH BZ 860158[1] Cannot login via Operating System Console into RHEL7
instance installed on a LPAR. This bugzilla actually blocks the installation
of Linux on System z instances in LPAR mode.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=860158
---
rules/99-systemd.rules.in |2 +-
src/getty-generator/getty-generator.c |4 +++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/rules/99-systemd.rules.in b/rules/99-systemd.rules.in
index 0923de5..021359a 100644
--- a/rules/99-systemd.rules.in
+++ b/rules/99-systemd.rules.in
@@ -7,7 +7,7 @@
ACTION==remove, GOTO=systemd_end
-SUBSYSTEM==tty, KERNEL==tty[a-zA-Z]*|hvc*|xvc*|hvsi*, TAG+=systemd
+SUBSYSTEM==tty, KERNEL==tty[a-zA-Z]*|hvc*|xvc*|hvsi*|ttysclp*|sclp_line*,
TAG+=systemd
KERNEL==vport*, TAG+=systemd
diff --git a/src/getty-generator/getty-generator.c
b/src/getty-generator/getty-generator.c
index aeb6d71..f352a29 100644
--- a/src/getty-generator/getty-generator.c
+++ b/src/getty-generator/getty-generator.c
@@ -97,7 +97,9 @@ int main(int argc, char *argv[]) {
static const char virtualization_consoles[] =
hvc0\0
xvc0\0
-hvsi0\0;
+hvsi0\0
+sclp_line0\0
+ttysclp0\0;
_cleanup_free_ char *active = NULL;
const char *j;
--
1.7.5.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] udev/net_id: Introduce predictable network names for Linux on System z
Use the bus-ID to create predicatable devices names for network interfaces
on Linux on System z instances. The bus-ID identifies a device in the s390
channel subsystem.
Network interfaces of device type Ethernet are named as:
enccw0.0.1234(13 characters)
up to
enccwff.7. (14 characters)
CTC network devices of device type SLIP, use a different prefix as follows:
slccw0.0.1234(13 characters)
See also Red Hat Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=870859
---
src/udev/udev-builtin-net_id.c | 64 ++-
1 files changed, 62 insertions(+), 2 deletions(-)
diff --git a/src/udev/udev-builtin-net_id.c b/src/udev/udev-builtin-net_id.c
index c322056..4f2b2c1 100644
--- a/src/udev/udev-builtin-net_id.c
+++ b/src/udev/udev-builtin-net_id.c
@@ -28,6 +28,7 @@
*
* Two character prefixes based on the type of interface:
* en -- ethernet
+ * sl -- serial line IP (slip)
* wl -- wlan
* ww -- wwan
*
@@ -102,6 +103,7 @@ enum netname_type{
NET_USB,
NET_BCMA,
NET_VIRTIO,
+NET_CCWGROUP,
};
struct netnames {
@@ -121,6 +123,8 @@ struct netnames {
char bcma_core[IFNAMSIZ];
char virtio_core[IFNAMSIZ];
+
+char ccw_core[IFNAMSIZ];
};
/* retrieve on-board index number and label from firmware */
@@ -366,6 +370,44 @@ static int names_virtio(struct udev_device *dev, struct
netnames *names) {
return 0;
}
+static int names_ccw(struct udev_device *dev, struct netnames *names) {
+struct udev_device *cdev;
+const char *bus_id;
+size_t bus_id_len;
+int rc;
+
+/* Retrieve the associated CCW device */
+cdev = udev_device_get_parent(dev);
+if (!cdev)
+return -ENOENT;
+
+/* Network devices are always grouped CCW devices */
+if (!streq_ptr(ccwgroup, udev_device_get_subsystem(cdev)))
+return -ENOENT;
+
+/* Retrieve bus-ID of the grouped CCW device. The bus-ID uniquely
+ * identifies the network device on the Linux on System z channel
+ * subsystem. Note that the bus-ID contains lowercase characters.
+ */
+bus_id = udev_device_get_sysname(cdev);
+if (!bus_id)
+return -ENOENT;
+
+/* Check the length of the bus-ID. Rely on that the kernel provides
+ * a correct bus-ID; alternatively, improve this check and parse and
+ * verify each bus-ID part...
+ */
+bus_id_len = strlen(bus_id);
+if (!bus_id_len || bus_id_len 8 || bus_id_len 9)
+return -EINVAL;
+
+/* Store the CCW bus-ID for use as network device name */
+rc = snprintf(names-ccw_core, sizeof(names-ccw_core), ccw%s,
bus_id);
+if (rc = 0 rc (int)sizeof(names-ccw_core))
+names-type = NET_CCWGROUP;
+return 0;
+}
+
static int names_mac(struct udev_device *dev, struct netnames *names) {
const char *s;
unsigned int i;
@@ -424,13 +466,21 @@ static int builtin_net_id(struct udev_device *dev, int
argc, char *argv[], bool
struct netnames names = {};
int err;
-/* handle only ARPHRD_ETHER devices */
+/* handle only ARPHRD_ETHER and ARPHRD_SLIP devices */
s = udev_device_get_sysattr_value(dev, type);
if (!s)
return EXIT_FAILURE;
i = strtoul(s, NULL, 0);
-if (i != 1)
+switch (i) {
+case 1: /* ARPHRD_ETHER */
+prefix = en;
+break;
+case 256: /* ARPHRD_SLIP */
+prefix = sl;
+break;
+default:
return 0;
+}
/* skip stacked devices, like VLANs, ... */
s = udev_device_get_sysattr_value(dev, ifindex);
@@ -462,6 +512,16 @@ static int builtin_net_id(struct udev_device *dev, int
argc, char *argv[], bool
ieee_oui(dev, names, test);
}
+/* get path names for Linux on System z network devices */
+err = names_ccw(dev, names);
+if (err = 0 names.type == NET_CCWGROUP) {
+char str[IFNAMSIZ];
+
+if (snprintf(str, sizeof(str), %s%s, prefix, names.ccw_core)
(int)sizeof(str))
+udev_builtin_add_property(dev, test,
ID_NET_NAME_PATH, str);
+goto out;
+}
+
/* get PCI based path names, we compose only PCI based paths */
err = names_pci(dev, names);
if (err 0)
--
1.7.5.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev/net_id: Introduce predictable network names for Linux on System z
Hi Tom, On Thu, Jan 09, 2014 at 12:46:55PM +0100, Tom Gundersen wrote: On Thu, Jan 9, 2014 at 11:28 AM, Hendrik Brueckner brueck...@redhat.com wrote: Use the bus-ID to create predicatable devices names for network interfaces on Linux on System z instances. The bus-ID identifies a device in the s390 channel subsystem. Looks good to me (assuming the names are truly stable between boots, as I have no idea about how the internals of this work in the kernel). The bus-IDs do not change across reboots. Could you also make sure that these things are supported by path_id when you are at it? We use that to reference devices from udev/networkd so makes sense if these things are in sync. Could you provide more information on that. I know that the path_id creates the ID_PATH environment variable for udev. There is already support in path_id for CCW devices used by network devices. I am not sure if that is already sufficient... So if you have some information, like the output of udevadm test-builtin path_id for a network devices, I can check how s390 behave in this. Anyhow, I would then address this on top of this issue. See also Red Hat Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=870859 Would be nice if you could post a summary, as a login is required. The network devices names switched between reboots and the systems where no longer accessible because the ip addresses were configured on the wrong network interface. Thanks and kind regards, Hendrik ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
