RE: [ACPI] RE: 'rmmod button' doesn't remove /proc/acpi/button

[Cagle, J. (ISS-Houston) <joh...@hp...>]

> From: Grover, Andrew [mailto:and...@in...]=20
> > From: Cagle, John (ISS-Houston) [mailto:joh...@hp...]
> > I found a minor bug in button.c's acpi_button_exit() routine.=20
> >  It doesn't remove the top-level 'button' directory when=20
> > unloading the module, and if you insmod/rmmod multiple times,=20
> > you'll end up with lots of 'button' directories in /proc/acpi.
>=20
> This actually reveals a bug in *all* of the client drivers.=20

Actually, all the other client drivers had code to remove
the class proc entry -- it was only missing from button.c's
unload logic.

> They all depend upon a global variable with the name=20
> acpi_{battery,button,etc}_dir to see if they need to make=20
> their class proc entry when adding their first device. This=20
> has the benefit of only creating a "button" directory if=20
> there actually is a button, but has the bad feature of not=20
> working for insmod...because the global variables go away,=20
> and so we blindly add the proc entries again.
>=20
> I think the best thing is to make the semantics "the proc dir=20
> is there if the driver is loaded, even with no devices=20
> present" instead of "the proc dir is there only if an actual=20
> instance of the device is present".
>=20
> This allows us to move the creation of the dir to the driver=20
> init function, instead of the device add function.
>=20
> Does that sound right?

That does sound like a cleaner approach.  Let me try it out
and see what the patch looks like.

>=20
> Regards -- Andy

Regards,
John
--------------------------------
John Cagle     joh...@hp...
Principal Member Technical Staff
   Industry Standard Servers
    Hewlett-Packard Company
    http://www.hp.com/linux
         281-514-9167