Hello, i just noticed that under some circumstances, ACPI WMI devices might fail to reprobe when being manually unbound and later rebound. Example: 1. ACPI WMI device #1 binds and registers WMI device with GUID "05901221-D566-11D1-B2F0-00A0C9062910", resulting in the device being named "05901221-D566-11D1-B2F0-00A0C9062910". 2. ACPI WMI device #2 binds and registers WMI device with GUID "05901221-D566-11D1-B2F0-00A0C9062910", resulting in the device being named "05901221-D566-11D1-B2F0-00A0C9062910-1". 3. ACPI WMI device #1 is manually unbound and later rebound, now the WMI device with GUID "05901221-D566-11D1-B2F0-00A0C9062910" is being named "05901221-D566-11D1-B2F0-00A0C9062910-1" too, since device naming depends on the number of GUIDs currently known to the WMI subsystem. 4. A WMI device named "05901221-D566-11D1-B2F0-00A0C9062910-1" already exists, causing the registration of the new WMI device to fail. I thought about some possible ways to solve this naming issue: - symlinks to simulate old WMI devices names, new WMI device names similar to "wmiX" with X being a global unique id - no symlinks, new WMI device names similar to "wmiX" with X being a global unique id - use global id instead of GUID number The first approach has full sysfs backward compatibility but i do not know how to create symlinks inside the "devices" directory. The second approach is the easiest and cleanest one, but provides no sysfs backward compatibility. The last approach provides only limited sysfs backward compatibility and only for programs which can handle "<GUID>-X" WMI device names. Currently, there is one single stable sysfs ABI entry concerning the WMI subsystem (for wmi-bmof), and two testing sysfs ABI entries (dell-wmi-privacy, sbl-fw-update). I do not know of any userspace programs relying on these ABIs, but i suspect there might be a couple of scripts which might be affected. Which approach should i take to solve this problem? Armin Wolf
