On Tuesday 05 February 2008 02:17:21 Carlos Corbacho wrote:
> Create a 'wmi' class, and populate it with a virtual device for each GUID.
> This also allows us to autoload WMI drivers based on GUID
> via MODULE_ALIAS.
>
> Under each GUID are a set of files that can be read and written to from
> userspace (these will be fully documented in a later patch).
>
> For now, the length of the GUID name/ directory is limited to 19
> characters, due to the current hardcoded limit on bus_id. When this is
> fixed, this can be changed in the code.
I'm starting to have some serious doubts about using sysfs for communicating
with userspace (I'm happy with the class/ virtual device ID idea, and I don't
see that being dropped, since it also solves the WMI autoloading problem
quite neatly - but the extra sysfs files added on to allow userspace to
interact with WMI are where I have a problem).
The problem is that a lot of the interactions with WMI are transactional - we
pass something in, and we expect to get something out, and we don't want
anything to happen in the middle to that data.
At the moment, this is the snippet of (Python) code I have to execute a WMI
method from userspace (instance and method_id in this case are just integers,
data_in and data_out can be any data structure, and are whatever the WMI
method accepts & returns, respectively):
def evaluate_method(guid, instance, method_id, data_in, data_out):
# Check that the instance is not bigger than the allowed maximum
# The maximum is defined by the GUID entry in the DSDT
instance_count_file = open(path + guid + "/instance_count", "r")
if int(instance) > int(instance_count_file.read()):
print "Instance is outside allowed maximum range"
exit()
instance_count_file.close()
# Specify the instance we want to execute
instance_file = open(path + guid + "/instance", "w")
instance_file.write(instance)
# Specify the method we want to execute
method_id_file = open(path + guid + "/method_id", "w")
method_id_file.write(method_id)
# Write the input data in
data_file = open(path + guid + "/data", "wb")
data_file.write(data_in)
data_file.close()
# Read the data back to trigger execution
data_file = open(path + guid + "/data", "rb")
data_out = data_file.read()
data_file.close()
method_id_file.close()
instance_file.close()
Unfortunately, as you can see this isn't nice, and very racy. To point out the
more glaring flaws:
1) instance and method_id can be changed before we start reading and writing
in any data.
2) Executing a method involves reading back from the 'data' file (but if we
don't care about the output, this makes little sense). If anything changes
before this, then either the method will fail, or we may not execute what we
intended to.
3) For method execution, this really comes across as rather 'clunky' means to
do so
At this point, I'm seriously looking into replacing the sysfs userspace
interface with ioctl's instead, but I'd like some thoughts either way, as I'm
not that sure where to go from here.
-Carlos
--
E-Mail: [EMAIL PROTECTED]
Web: strangeworlds.co.uk
GPG Key ID: 0x23EE722D
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
