[PATCH][ACPI][BUTTON] remove procfs-interface

[PATCH][ACPI][BUTTON] remove procfs-interface

[Henne]

Removes the proc_fs interface from the ACPI button driver.
Signed-off-by: Henrik Kretzschmar <henne@nachtwindheim.de>

---

 Documentation/feature-removal-schedule.txt |    8 -
 drivers/acpi/button.c                      |  195 -----------------------------
 2 files changed, 2 insertions(+), 201 deletions(-)

diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 3a159da..a33354b 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -240,14 +240,6 @@ Who:	Zhang Rui <rui.zhang@intel.com>
 
 ---------------------------
 
-What:	/proc/acpi/button
-When:	August 2007
-Why:	/proc/acpi/button has been replaced by events to the input layer
-	since 2.6.20.
-Who:	Len Brown <len.brown@intel.com>
-
----------------------------
-
 What:	Compaq touchscreen device emulation
 When:	Oct 2007
 Files:	drivers/input/tsdev.c
diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c
index cb4110b..574041b 100644
--- a/drivers/acpi/button.c
+++ b/drivers/acpi/button.c
@@ -27,17 +27,11 @@
 #include <linux/module.h>
 #include <linux/init.h>
 #include <linux/types.h>
-#include <linux/proc_fs.h>
-#include <linux/seq_file.h>
 #include <linux/input.h>
 #include <acpi/acpi_bus.h>
 #include <acpi/acpi_drivers.h>
 
-#define ACPI_BUTTON_COMPONENT		0x00080000
 #define ACPI_BUTTON_CLASS		"button"
-#define ACPI_BUTTON_FILE_INFO		"info"
-#define ACPI_BUTTON_FILE_STATE		"state"
-#define ACPI_BUTTON_TYPE_UNKNOWN	0x00
 #define ACPI_BUTTON_NOTIFY_STATUS	0x80
 
 #define ACPI_BUTTON_SUBCLASS_POWER	"power"
@@ -59,7 +53,6 @@
 #define ACPI_BUTTON_DEVICE_NAME_LID	"Lid Switch"
 #define ACPI_BUTTON_TYPE_LID		0x05
 
-#define _COMPONENT		ACPI_BUTTON_COMPONENT
 ACPI_MODULE_NAME("button");
 
 MODULE_AUTHOR("Paul Diefenbaugh");
@@ -68,8 +61,6 @@ MODULE_LICENSE("GPL");
 
 static int acpi_button_add(struct acpi_device *device);
 static int acpi_button_remove(struct acpi_device *device, int type);
-static int acpi_button_info_open_fs(struct inode *inode, struct file *file);
-static int acpi_button_state_open_fs(struct inode *inode, struct file *file);
 
 static struct acpi_driver acpi_button_driver = {
 	.name = "button",
@@ -89,161 +80,6 @@ struct acpi_button {
 	unsigned long pushed;
 };
 
-static const struct file_operations acpi_button_info_fops = {
-	.open = acpi_button_info_open_fs,
-	.read = seq_read,
-	.llseek = seq_lseek,
-	.release = single_release,
-};
-
-static const struct file_operations acpi_button_state_fops = {
-	.open = acpi_button_state_open_fs,
-	.read = seq_read,
-	.llseek = seq_lseek,
-	.release = single_release,
-};
-
-/* --------------------------------------------------------------------------
-                              FS Interface (/proc)
-   -------------------------------------------------------------------------- */
-
-static struct proc_dir_entry *acpi_button_dir;
-
-static int acpi_button_info_seq_show(struct seq_file *seq, void *offset)
-{
-	struct acpi_button *button = seq->private;
-
-	if (!button || !button->device)
-		return 0;
-
-	seq_printf(seq, "type:                    %s\n",
-		   acpi_device_name(button->device));
-
-	return 0;
-}
-
-static int acpi_button_info_open_fs(struct inode *inode, struct file *file)
-{
-	return single_open(file, acpi_button_info_seq_show, PDE(inode)->data);
-}
-
-static int acpi_button_state_seq_show(struct seq_file *seq, void *offset)
-{
-	struct acpi_button *button = seq->private;
-	acpi_status status;
-	unsigned long state;
-
-	if (!button || !button->device)
-		return 0;
-
-	status = acpi_evaluate_integer(button->device->handle, "_LID", NULL, &state);
-	seq_printf(seq, "state:      %s\n",
-		   ACPI_FAILURE(status) ? "unsupported" :
-			(state ? "open" : "closed"));
-	return 0;
-}
-
-static int acpi_button_state_open_fs(struct inode *inode, struct file *file)
-{
-	return single_open(file, acpi_button_state_seq_show, PDE(inode)->data);
-}
-
-static struct proc_dir_entry *acpi_power_dir;
-static struct proc_dir_entry *acpi_sleep_dir;
-static struct proc_dir_entry *acpi_lid_dir;
-
-static int acpi_button_add_fs(struct acpi_device *device)
-{
-	struct proc_dir_entry *entry = NULL;
-	struct acpi_button *button;
-
-	if (!device || !acpi_driver_data(device))
-		return -EINVAL;
-
-	button = acpi_driver_data(device);
-
-	switch (button->type) {
-	case ACPI_BUTTON_TYPE_POWER:
-	case ACPI_BUTTON_TYPE_POWERF:
-		if (!acpi_power_dir)
-			acpi_power_dir = proc_mkdir(ACPI_BUTTON_SUBCLASS_POWER,
-						    acpi_button_dir);
-		entry = acpi_power_dir;
-		break;
-	case ACPI_BUTTON_TYPE_SLEEP:
-	case ACPI_BUTTON_TYPE_SLEEPF:
-		if (!acpi_sleep_dir)
-			acpi_sleep_dir = proc_mkdir(ACPI_BUTTON_SUBCLASS_SLEEP,
-						    acpi_button_dir);
-		entry = acpi_sleep_dir;
-		break;
-	case ACPI_BUTTON_TYPE_LID:
-		if (!acpi_lid_dir)
-			acpi_lid_dir = proc_mkdir(ACPI_BUTTON_SUBCLASS_LID,
-						  acpi_button_dir);
-		entry = acpi_lid_dir;
-		break;
-	}
-
-	if (!entry)
-		return -ENODEV;
-	entry->owner = THIS_MODULE;
-
-	acpi_device_dir(device) = proc_mkdir(acpi_device_bid(device), entry);
-	if (!acpi_device_dir(device))
-		return -ENODEV;
-	acpi_device_dir(device)->owner = THIS_MODULE;
-
-	/* 'info' [R] */
-	entry = create_proc_entry(ACPI_BUTTON_FILE_INFO,
-				  S_IRUGO, acpi_device_dir(device));
-	if (!entry)
-		return -ENODEV;
-	else {
-		entry->proc_fops = &acpi_button_info_fops;
-		entry->data = acpi_driver_data(device);
-		entry->owner = THIS_MODULE;
-	}
-
-	/* show lid state [R] */
-	if (button->type == ACPI_BUTTON_TYPE_LID) {
-		entry = create_proc_entry(ACPI_BUTTON_FILE_STATE,
-					  S_IRUGO, acpi_device_dir(device));
-		if (!entry)
-			return -ENODEV;
-		else {
-			entry->proc_fops = &acpi_button_state_fops;
-			entry->data = acpi_driver_data(device);
-			entry->owner = THIS_MODULE;
-		}
-	}
-
-	return 0;
-}
-
-static int acpi_button_remove_fs(struct acpi_device *device)
-{
-	struct acpi_button *button = acpi_driver_data(device);
-
-	if (acpi_device_dir(device)) {
-		if (button->type == ACPI_BUTTON_TYPE_LID)
-			remove_proc_entry(ACPI_BUTTON_FILE_STATE,
-					  acpi_device_dir(device));
-		remove_proc_entry(ACPI_BUTTON_FILE_INFO,
-				  acpi_device_dir(device));
-
-		remove_proc_entry(acpi_device_bid(device),
-				  acpi_device_dir(device)->parent);
-		acpi_device_dir(device) = NULL;
-	}
-
-	return 0;
-}
-
-/* --------------------------------------------------------------------------
-                                Driver Interface
-   -------------------------------------------------------------------------- */
-
 static void acpi_button_notify(acpi_handle handle, u32 event, void *data)
 {
 	struct acpi_button *button = data;
@@ -405,13 +241,9 @@ static int acpi_button_add(struct acpi_d
 		goto err_free_input;
 	}
 
-	error = acpi_button_add_fs(device);
-	if (error)
-		goto err_free_input;
-
 	error = acpi_button_install_notify_handlers(button);
 	if (error)
-		goto err_remove_fs;
+		goto err_free_input;
 
 	snprintf(button->phys, sizeof(button->phys),
 		 "%s/button/input0", acpi_device_hid(device));
@@ -461,8 +293,6 @@ static int acpi_button_add(struct acpi_d
 
  err_remove_handlers:
 	acpi_button_remove_notify_handlers(button);
- err_remove_fs:
-	acpi_button_remove_fs(device);
  err_free_input:
 	input_free_device(input);
  err_free_button:
@@ -480,7 +310,6 @@ static int acpi_button_remove(struct acp
 	button = acpi_driver_data(device);
 
 	acpi_button_remove_notify_handlers(button);
-	acpi_button_remove_fs(device);
 	input_unregister_device(button->input);
 	kfree(button);
 
@@ -489,32 +318,12 @@ static int acpi_button_remove(struct acp
 
 static int __init acpi_button_init(void)
 {
-	int result;
-
-	acpi_button_dir = proc_mkdir(ACPI_BUTTON_CLASS, acpi_root_dir);
-	if (!acpi_button_dir)
-		return -ENODEV;
-	acpi_button_dir->owner = THIS_MODULE;
-	result = acpi_bus_register_driver(&acpi_button_driver);
-	if (result < 0) {
-		remove_proc_entry(ACPI_BUTTON_CLASS, acpi_root_dir);
-		return -ENODEV;
-	}
-
-	return 0;
+	return acpi_bus_register_driver(&acpi_button_driver);
 }
 
 static void __exit acpi_button_exit(void)
 {
 	acpi_bus_unregister_driver(&acpi_button_driver);
-
-	if (acpi_power_dir)
-		remove_proc_entry(ACPI_BUTTON_SUBCLASS_POWER, acpi_button_dir);
-	if (acpi_sleep_dir)
-		remove_proc_entry(ACPI_BUTTON_SUBCLASS_SLEEP, acpi_button_dir);
-	if (acpi_lid_dir)
-		remove_proc_entry(ACPI_BUTTON_SUBCLASS_LID, acpi_button_dir);
-	remove_proc_entry(ACPI_BUTTON_CLASS, acpi_root_dir);
 }
 
 module_init(acpi_button_init);

Re: [PATCH][BUTTON] remove procfs-interface

[Arjan van de Ven]

On Thu, 2007-07-12 at 10:58 +0200, Henne wrote:
> Removes the proc_fs interface from the ACPI button driver.
> Signed-off-by: Henrik Kretzschmar <henne@nachtwindheim.de>
> 
> ---

you forgot to say why.....

Re: [PATCH][BUTTON] remove procfs-interface

[Henne]

Arjan van de Ven wrote:

> On Thu, 2007-07-12 at 10:58 +0200, Henne wrote:
>   
>> Removes the proc_fs interface from the ACPI button driver.
>> Signed-off-by: Henrik Kretzschmar <henne@nachtwindheim.de>
>>
>> ---
>>     
>
> you forgot to say why.....
>
>
>   
First, because refering to /Documentation/feature-removal-schedule.txt it should be done:

>What:   /proc/acpi/button
>When:   August 2007
>Why:    /proc/acpi/button has been replaced by events to the input layer
>        since 2.6.20.
>Who:    Len Brown <len.brown@intel.com>

Second, refering to /Documentation/feature-removal-schedule.txt
 
>What:   ACPI procfs interface
>When:   July 2007
>Why:    After ACPI sysfs conversion, ACPI attributes will be duplicated
>        in sysfs and the ACPI procfs interface should be removed.
>Who:    Zhang Rui <rui.zhang@intel.com>

The button driver uses acpi_root_dir which won't be available if acpi is removed this month.
That would lead to errors, I think.

RE: [PATCH][BUTTON] remove procfs-interface

[Zhang, Rui]

Well, the ACPI sysfs conversion is not finished yet
and some user space tools still use the ACPI procfs.
The schedule of removing ACPI procfs I/F will be changed to Jan 08.
I'm about to send a patch to update it.

I'm not sure if the button sysfs I/F is already finished.
We'd better make a double check. :)

Thanks,
Rui

-----Original Message-----
From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-owner@vger.kernel.org] On Behalf Of Henne
Sent: 2007年7月12日 17:41
To: Arjan van de Ven
Cc: Brown, Len; linux-acpi@vger.kernel.org; akpm@linux-foundation.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH][ACPI][BUTTON] remove procfs-interface

Arjan van de Ven wrote:

> On Thu, 2007-07-12 at 10:58 +0200, Henne wrote:
>   
>> Removes the proc_fs interface from the ACPI button driver.
>> Signed-off-by: Henrik Kretzschmar <henne@nachtwindheim.de>
>>
>> ---
>>     
>
> you forgot to say why.....
>
>
>   
First, because refering to /Documentation/feature-removal-schedule.txt it should be done:

>What:   /proc/acpi/button
>When:   August 2007
>Why:    /proc/acpi/button has been replaced by events to the input layer
>        since 2.6.20.
>Who:    Len Brown <len.brown@intel.com>

Second, refering to /Documentation/feature-removal-schedule.txt
 
>What:   ACPI procfs interface
>When:   July 2007
>Why:    After ACPI sysfs conversion, ACPI attributes will be duplicated
>        in sysfs and the ACPI procfs interface should be removed.
>Who:    Zhang Rui <rui.zhang@intel.com>

The button driver uses acpi_root_dir which won't be available if acpi is removed this month.
That would lead to errors, I think.



-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH][BUTTON] remove procfs-interface

[Richard Hughes]

On Thu, 2007-07-12 at 17:46 +0800, Zhang, Rui wrote:
> 
> I'm not sure if the button sysfs I/F is already finished.
> We'd better make a double check. :)

We need a button sysfs interface? What's wrong with just using input?

Richard.

RE: [PATCH][BUTTON] remove procfs-interface

[Brown, Len]

The last time I tried to remove this code,
we discovered that people were using it to query
the lid (button) status.

-Len 

>-----Original Message-----
>From: Richard Hughes [mailto:hughsient@gmail.com] 
>Sent: Thursday, July 12, 2007 6:26 AM
>To: Zhang, Rui
>Cc: Henne; Arjan van de Ven; Brown, Len; 
>linux-acpi@vger.kernel.org; akpm@linux-foundation.org; 
>linux-kernel@vger.kernel.org
>Subject: RE: [PATCH][ACPI][BUTTON] remove procfs-interface
>
>On Thu, 2007-07-12 at 17:46 +0800, Zhang, Rui wrote:
>> 
>> I'm not sure if the button sysfs I/F is already finished.
>> We'd better make a double check. :)
>
>We need a button sysfs interface? What's wrong with just using input?
>
>Richard.
>

Re: [PATCH][BUTTON] remove procfs-interface

[Satyam Sharma]

On 7/12/07, Zhang, Rui <rui.zhang@intel.com> wrote:
> Well, the ACPI sysfs conversion is not finished yet
> [...]
> I'm not sure if the button sysfs I/F is already finished.
> We'd better make a double check. :)

Ok, this sounds reasonable.

> and some user space tools still use the ACPI procfs.

But this does *not*, IMHO. It quite defeats the whole concept of
feature-removal-schedule.txt. I think that file exists precisely
because we cannot gratuitously break userspace interfaces just
like that, but when something gets put up there with a removal date
that is a good one year in the future, and userspace tools _still_
continue to use it ... then, I suspect something's seriously wrong.

Either the feature-removal-schedule.txt file has become something
that users don't even bother checking, or else, they _know_ that
even if they don't bother keeping up with the pace in kernel-land,
that interface still won't go away (because they're still using it!).
In both the above cases, it appears that file itself has become
irrelevant and a "feature" that could be "removed" ... :-)

> The schedule of removing ACPI procfs I/F will be changed to Jan 08.
> I'm about to send a patch to update it.

Satyam

Re: [PATCH][BUTTON] remove procfs-interface

[Zhang Rui]

On Fri, 2007-07-13 at 03:07 +0800, Satyam Sharma wrote:
> On 7/12/07, Zhang, Rui <rui.zhang@intel.com> wrote:
> > Well, the ACPI sysfs conversion is not finished yet
> > [...]
> > I'm not sure if the button sysfs I/F is already finished.
> > We'd better make a double check. :)
> 
> Ok, this sounds reasonable.
> 
> > and some user space tools still use the ACPI procfs.
> 
> But this does *not*, IMHO. It quite defeats the whole concept of
> feature-removal-schedule.txt. I think that file exists precisely
> because we cannot gratuitously break userspace interfaces just
> like that, but when something gets put up there with a removal date
> that is a good one year in the future, and userspace tools _still_
> continue to use it ... then, I suspect something's seriously wrong.
> 
Hi, Satyam,
Here I mean the sysfs conversion is not finished, like some ACPI
device/driver attributes.
i.e. we don't have the alternative in sysfs for all the ACPI proc I/F,
which means that part of the ACPI proc I/F are still needed.

> Either the feature-removal-schedule.txt file has become something
> that users don't even bother checking, or else, they _know_ that
> even if they don't bother keeping up with the pace in kernel-land,
> that interface still won't go away (because they're still using it!).
> In both the above cases, it appears that file itself has become
> irrelevant and a "feature" that could be "removed" ... :-)

Thanks,
Rui

Re: [PATCH][BUTTON] remove procfs-interface

[Stefan Seyfried]

On Fri, Jul 13, 2007 at 12:37:07AM +0530, Satyam Sharma wrote:
> On 7/12/07, Zhang, Rui <rui.zhang@intel.com> wrote:
> >Well, the ACPI sysfs conversion is not finished yet
> >[...]
> >I'm not sure if the button sysfs I/F is already finished.
> >We'd better make a double check. :)
> 
> Ok, this sounds reasonable.
> 
> >and some user space tools still use the ACPI procfs.
> 
> But this does *not*, IMHO. It quite defeats the whole concept of
> feature-removal-schedule.txt. I think that file exists precisely
> because we cannot gratuitously break userspace interfaces just
> like that, but when something gets put up there with a removal date
> that is a good one year in the future, and userspace tools _still_
> continue to use it ... then, I suspect something's seriously wrong.

Holy sh*t. There is not even a functional replacement ready, but still
everybody wants to remove /proc/acpi. (Maybe the replacement started
to work recently, i have not looked into this area for the last months.
This does not change my pint, though).
This is not going to work.
IMNSHO, we need the new interface available and usable for quite some time
(i'd say for over one year), and then we can start to phase out the old
interface.
Starting with removing /proc/acpi is not the correct ordering of actions.
 
> Either the feature-removal-schedule.txt file has become something
> that users don't even bother checking, or else, they _know_ that
> even if they don't bother keeping up with the pace in kernel-land,
> that interface still won't go away (because they're still using it!).

Or they look at the feature-removal document, find out that there is
no replacement available and conclude "the writers of this document
must have been on crack, or this document is unmaintained". I cannot
disagree with them.
-- 
Stefan Seyfried
QA / R&D Team Mobile Devices        |              "Any ideas, John?"
SUSE LINUX Products GmbH, Nürnberg  | "Well, surrounding them's out." 

This footer brought to you by insane German lawmakers:
SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)

Re: [PATCH][BUTTON] remove procfs-interface

[Satyam Sharma]

On 7/16/07, Stefan Seyfried <seife@suse.de> wrote:

> Holy sh*t. There is not even a functional replacement ready, but still
> everybody wants to remove /proc/acpi. (Maybe the replacement started
> to work recently, i have not looked into this area for the last months.
> This does not change my pint, though).
> This is not going to work.
> IMNSHO, we need the new interface available and usable for quite some time
> (i'd say for over one year), and then we can start to phase out the old
> interface.
> Starting with removing /proc/acpi is not the correct ordering of actions.

Heh, you're 3 days late to the party, but yeah, Zhang's corrected me/
pointed this out (the functionality in /proc/acpi not yet in the sysfs I/F
being used by said userspace tools) already. I guess I had originally
misunderstood the "some user space tools still use the ACPI procfs" bit.

Satyam