Re: RE: 'rmmod button' doesn't remove /proc/acpi/button

[Dominik Brodowski <linux-JhLEnvuH02M@public.gmane.org>]

On Mon, Nov 11, 2002 at 12:01:35PM -0800, Grover, Andrew wrote:
> > From: Cagle, John (ISS-Houston) [mailto:john.cagle-VXdhtT5mjnY@public.gmane.org] 
> > I found a minor bug in button.c's acpi_button_exit() routine. 
> >  It doesn't remove the top-level 'button' directory when 
> > unloading the module, and if you insmod/rmmod multiple times, 
> > you'll end up with lots of 'button' directories in /proc/acpi.
> 
> This actually reveals a bug in *all* of the client drivers. They all depend
> upon a global variable with the name acpi_{battery,button,etc}_dir to see if
> they need to make their class proc entry when adding their first device.
> This has the benefit of only creating a "button" directory if there actually
> is a button, but has the bad feature of not working for insmod...because the
> global variables go away, and so we blindly add the proc entries again.
> 
> I think the best thing is to make the semantics "the proc dir is there if
> the driver is loaded, even with no devices present" instead of "the proc dir
> is there only if an actual instance of the device is present".
> 
> This allows us to move the creation of the dir to the driver init function,
> instead of the device add function.

Actually, I think this would confuse users even more than currently: If an
OSPM-module is loaded, but no entry is found in the DSDT (or anywhere), it
is still loaded; doesn't complain in dmesg (actually, doesn't add any output
to dmesg) and so causes some users to think "well, everything seems to be
working fine". Now, if the proc dir is added even if no such device is
added, the confusion enlargens.

Instead, I'd propose adding an acpi_{battery,button,etc}_dir_count, and when
this reaches zero in acpi_button_remove_fs(), for example, remove_proc_entry
the acpi_button_dir.

	Dominik 
who is very busy at the moment, else I'd write a patch :-)


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf