------- Comment From [email protected] 2017-03-27 04:19 EDT------- (In reply to comment #8) > I do not see bridge_role file available until after the three devices in a > group are online. > As in the file is not in sysfs when the qeth devices are offline (and have > not yet been ever onlined yet aka absolutely fresh boot) > > Why should I be specifying the layer2 attribute, if it is the default? That > violates the DRY principle. > > Or specifically, shouldn't specifying bridge_role=primary; trigger > generation of the layer2=1 attribute in the generated udev rules file?!
The qeth device driver registers the layer2-specific attributes either when the layer2 attribute is set, or when the device is set online and the driver determines that layer2=1 is the correct setting. This explains the original error reported in this bug report: the udev rule tried to write to the bridge_role attribute even though it did not yet exist, resulting in a "permission denied" error (because the directory is not writable). This is the result of a somewhat incomplete design assumption - for z/VM guests, chzdev determines the layer2 setting based on Hypervisor information, so the sorting implemented by chzdev (bridge_role after layer2) works. It does not work however, when the value of the layer2-setting is left to the device driver, as in the LPAR case. We cannot simply change the ordering of all layer2-specific attributes to "after online", because some of these (e.g. sniffer, hsuid) can only be set after layer2 was set and before online is set. I think the idea you proposes in your latest comment sounds like a good approach: if a user specifies a layer2-specific attribute, and layer2 is not set, that is: - not auto-detected by chzdev as under z/VM - not set persistently by a previous invocation - not set by this invocation, then chzdev could generate layer=1 implicitly, and issue an informational message to indicate the same. Additionally, if a layer2-specific attribute is set and the layer2-attribute is set to 0 (set persistently before, or specified during this invocation), chzdev should abort with an error. We'll evaluate how this is best implemented in chzdev. In the mean-time, specifying layer=1 can be used as a work-around in such cases. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1672650 Title: chzdev ccwgroup qeth properties incorrect ordering with respect to online To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1672650/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
