Re: [PATCH v3] ACPI: platform-profile: Add platform profile support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux