Re: [PATCH] Introduce support for Systems Management Driver over WMI for Dell Systems
From: Hans de Goede
Date: Tue Sep 22 2020 - 04:57:42 EST
On 9/21/20 5:26 PM, Limonciello, Mario wrote:
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 ?
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:
Which works 90% the same as:
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
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.