WMI probe failure when reprobing

[Armin Wolf]

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