* In this generic way they don't look plausible. If we *always* want hotplugged CPUs and memory to be online (which sounds plausible), then the kernel should do just that. It shouldn't require lots of extra userspace overhead to always set a driver attribute to a constant value. It is certainly ok as a workaround until the kernel gets fixed properly, though.
* If this applies to Hyper-V only, it would be better to surround these rules with some check if the system is actually running on this hypervisor. This might happen via DMI data (like ATTR{[dmi/id]product_version}=="hyper-v"), the presence of a Hyper-V specific device/subsystem in sysfs, and so on. This ATTR{[subsystem/device]attribute} syntax works generically by the way, so that you can look at a device different than the one you are currently selecting.
Please don't apply this udev rule as it is:
* It can be made *much* more efficient and avoid an extra shell with
SUBSYSTEM= ="memory" , ACTION=="add", DEVPATH= ="/devices/ system/ memory/ memory* [0-9]", ATTR{online}="1"
(same for the other rule)
* In this generic way they don't look plausible. If we *always* want hotplugged CPUs and memory to be online (which sounds plausible), then the kernel should do just that. It shouldn't require lots of extra userspace overhead to always set a driver attribute to a constant value. It is certainly ok as a workaround until the kernel gets fixed properly, though.
* If this applies to Hyper-V only, it would be better to surround these rules with some check if the system is actually running on this hypervisor. This might happen via DMI data (like ATTR{[dmi/ id]product_ version} =="hyper- v"), the presence of a Hyper-V specific device/subsystem in sysfs, and so on. This ATTR{[subsystem /device] attribute} syntax works generically by the way, so that you can look at a device different than the one you are currently selecting.