Messages in this thread | | | Subject | Re: [PATCH] Introduce support for Systems Management Driver over WMI for Dell Systems | From | Hans de Goede <> | Date | Tue, 22 Sep 2020 10:57:33 +0200 |
| |
Hi,
On 9/21/20 5:26 PM, Limonciello, Mario wrote:
<snip>
I will do another more detailed reply in another email, but I would like to focus at the main pain point here, which is the using a generic sysfs-ABI/class vs using a Dell specific sysfs-ABI.
>> I guess a could way to look at the generic sysfs firmware attributes >> class I'm proposing is looking at it as a lowest common denominator >> solution. With the addition of vendor specific extensions so that >> vendors (e.g. Dell) are not limited to only offering functionality >> offered by the generic, shared ABI. Does that make sense ? >> >> Regards, >> > > I really think that trying to fit all the vendors into the same interface is going > to stifle areas for innovation in the firmware and kernel space in the name of > "simplicity" which really only goes as far as the kernel side. Userspace has > to carry delta between vendors no matter what, so why introduce a LCD then? > > Just as easily we could have: > /sys/devices/platform/dell-wmi-sysman/attributes/ > > Which works 90% the same as: > /sys/devices/platform/lenovo-wmi-sysman/attributes/
So the reason why I want a class interface for this is to allow say FleetCommander to have a generic plugin implementing that 90%, so no deps, only support plain admin-password authentication.
Allowing such a generic plugin requires 2 things:
1) Ensuring that the 90% overlapping functionality offers a 100% identical userspace ABI, thus a shared sysfs ABI definition
2) That userspace has a generic way to enumerate devices/drivers implementing this shared sysfs ABI, and we have a standard mechanism for enumerating drivers which implement a standard ABI, that is we make them register class devices under /sys/class/<abi-name>.
I have not heard any convincing arguments against why would should not or can not have these 2 things. All I'm hearing is a vague fear that this may "stifle areas for innovation in the firmware and kernel space".
Honestly I have the feeling we are going in circles in this discussion and I really do not understand why you are so dead set against having a common sysfs ABI/class for this?
In part of the snipped text you write "Having to de-feature the sysfs interface", but I have not asked you to remove any features anywhere in this thread!
So I really do not understand where this fear of not being able to implement certain, possibly Dell specific, features comes from?
You mentioned that the way the dependencies are expressed are highly Dell specific, so I suggested allowing having vendor extensions like dell-modifiers and dell-value_modifiers. The whole idea behind allowing vendor-extensions is actually the exact opposite of de-featuring the sysfs interface.
Regards,
Hans
| |