vmur devices fail to enable on boot, missing driver stanzas in udev rules

[xnox]

$ sudo chzdev -e 000c 000d 000e
$ sudo update-initramfs -u
$ sudo reboot
$ lszdev # 000c 000d 000e are not active
$ sudo systemctl restart systemd-udev-trigger # onlines the missing devices, as vmur module is loaded now

vmur devices such as 000c, 000d, 000e are treated as generic_ccw_subtype devices by zdev. This leads to generating stock udev rules that are only triggered upon devices additions.

The rules are not triggered when a vmur driver is bound to them.

Typically on Ubuntu systems, vmur driver is loaded after systemd-udev-trigger.service is already inflight, and thus 000c, 000d, 000e are not activated on boot.

However, adding

ACTION=="add", SUBSYSTEM=="drivers", KERNEL=="vmur", TEST=="[ccw/0.0.000c]", GOTO="cfg_generic_ccw_0.0.000c"`

Just before GOTO="end_ makes the device be activated.

I'm not sure if we want to create a new vmur subtype in zdev, or somehow extend generic_ccw_subtype to inject vmur data instead of &generic_ccw_data.

Ubuntu bug report is: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1794308

[xnox]

I think vmur devices need to become either a top level type, or a subtype of generic. Getting a bit lost in the code, as to where it is the easiest to override this.

[hoeppnerj]

@oberpar and @hbrueckner can you guys have a look at it?

[oberpar]

A new subtype for vmur seems like overkill to me (and would need to be repeated for every other generic-ccw device type).

I can think of an easy way to handle this within the existing generic-ccw subtype:

• ccw.h: add a new field 'bool any_driver' to struct ccw_subtype_data
• generic_ccw.c: set generic_ccw_data.any_driver to true
• udev_ccw.c: if data->ccwdrv is not set, but data->any_driver is set, use "*" as drv

This will result in a udev rule that will try to enable the device whenever any driver is loaded. There are some side-effects:

• for all other drivers loaded before vmur, udev will try to set the device online which will quickly fail due to no bound driver: this should not be a problem (no error message in any logs)
• when the device is offline in the active configuration and online in the persistent configuration, loading any module will set the device online: this is a rather special situation for which I would not consider this a bug (the device is intended to be online anyway)

I'm not sure when I will get to work on implementing this approach though.

[xnox]

That's a good and easy start. Plus I hope that generic_ccw devices are not that many / are not typical to have enabled like that.

Also, if we are on the system and onlining the device, should we not attempt to read the actual driver with ccw_get_driver() and encode whatever that says?

[xnox]

ehm.... doesn't all of the above simply then reduces to simply setting generic_ccw_data.ccwdrv = "*" without a need to actually add the any_driver bool.