Re: [Kernel-discuss] Re: [PATCH 7/7] [RFC] APM emulation driver for class batteries

[Paul Sokolovsky <pmiscml@gmail.com>]

Hello Russell,

Monday, April 16, 2007, 11:24:21 PM, you wrote:

> On Fri, Apr 13, 2007 at 05:50:43PM +0400, Anton Vorontsov wrote:
>> +static void (*old_apm_get_power_status)(struct apm_power_info*);
>> +
>> +static int __init apm_battery_init(void)
>> +{
>> +     printk(KERN_INFO "APM Battery Driver\n");
>> +
>> +     old_apm_get_power_status = apm_get_power_status;
>> +     apm_get_power_status = apm_battery_apm_get_power_status;
>> +     return 0;
>> +}
>> +
>> +static void __exit apm_battery_exit(void)
>> +{
>> +     apm_get_power_status = old_apm_get_power_status;
>> +     return;
>> +}

> Utterly unsafe.  What happens if some other module gets loaded which
> does this, and then this module is unloaded followed by the other
> module.  Result: Oops.

	That's apparently why "APM emulation" goes on its way towards deprecation, right? And why people so detailed about new battery API, as it's everyone's hope that it should replace APM.

	We exactly provide APM emulation on top of battery API as separate driver because of such issues with APM API. Anyway, any suggestions on solving this "pointer API" issue? Would at least assigning NULL on exit be more safe? (Because yes, there just shouldn't be two APM drivers, and for the weird case there're, it would be nice to at least not segfault.)



-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com