On 20/11/2020 14:50, Barnabás Pőcze wrote:
Hi
2020. november 15., vasárnap 1:44 keltezéssel, Mark Pearson írta:
[...]
+int platform_profile_register(struct platform_profile_handler *pprof)
+{
+ mutex_lock(&profile_lock);
+ /* We can only have one active profile */
+ if (cur_profile) {
+ mutex_unlock(&profile_lock);
+ return -EEXIST;
+ }
+
+ cur_profile = pprof;
+ mutex_unlock(&profile_lock);
+ return sysfs_create_group(acpi_kobj, &platform_profile_group);
+}
+EXPORT_SYMBOL_GPL(platform_profile_register);
+
+int platform_profile_unregister(void)
+{
+ mutex_lock(&profile_lock);
+ sysfs_remove_group(acpi_kobj, &platform_profile_group);
+ cur_profile = NULL;
+ mutex_unlock(&profile_lock);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(platform_profile_unregister);
[...]
I just realized that the sysfs attributes are only created if a profile provider
is registered, and it is removed when the provide unregisters itself. I believe
it would be easier for system daemons if those attributes existed from module load
to module unload since they can just just open the file and watch it using poll,
select, etc. If it goes away when the provider unregisters itself, then I believe
a more complicated mechanism (like inotify) would need to be implemented in the
daemons to be notified when a new provider is registered. Thus my suggestion
for the next iteration is to create the sysfs attributes on module load,
and delete them on unload.
What do you think?
Regards,
Barnabás Pőcze
Good point. I'd like to have input from user space as to their
preference - it seems like a simple enough change to make and I'm happy
to go with what their preferences are. Bastien - would this make life
easier for you?
Perhaps when the provider unregisters it sends a sysfs_notify and user
space can look and detect/handle that condition (I think it will get
EOPNOTSUPP on the next read). Is there something cleverer it can do?
Thanks
Mark
