remove procfs-interface
Subsystems (2)
PATCH 1/1 remove procfs-interface
Removes the proc_fs interface from the ACPI button driver.
---
Documentation/feature-removal-schedule.txt | 8 - drivers/acpi/button.c | 195 ----------------------------- 2 files changed, 2 insertions(+), 201 deletions(-)
Documentation/feature-removal-schedule.txt +0 -8
@@ -240,14 +240,6 @@ Who: Zhang Rui <[email protected]> --------------------------- -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 <[email protected]> - ---------------------------- - What: Compaq touchscreen device emulation When: Oct 2007 Files: drivers/input/tsdev.c
drivers/acpi/button.c +2 -193
255 lines not on this page · raw message
Quoted 4 lines · Henne
Removes the
proc_fsinterface from the ACPI button driver.Signed-off-by Henrik Kretzschmar <[email protected]>---
you forgot to say why.....
Quoted 12 lines · Arjan van de Ven
Quoted 5 lines · Henne
Removes the
proc_fsinterface from the ACPI button driver.Signed-off-by Henrik Kretzschmar <[email protected]>---
you forgot to say why.....
First, because refering to /Documentation/feature-removal-schedule.txt it should be done:
Quoted 5 lines
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 <[email protected]>
Second, refering to /Documentation/feature-removal-schedule.txt
Quoted 5 lines
What: ACPI procfs interface When: July 2007 Why: After ACPI sysfs conversion, ACPI attributes will be duplicatedin sysfs and the ACPI procfs interface should be removed.
Who: Zhang Rui <[email protected]>
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.
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: [email protected] [mailto:[email protected]] On Behalf Of Henne
Sent: 2007年7月12日 17:41
To: Arjan van de Ven
Cc: Brown, Len; [email protected]; [email protected]; [email protected]
Subject: Re: [PATCH][ACPI][BUTTON] remove procfs-interface
Quoted 12 lines · Arjan van de Ven
Quoted 5 lines · Henne
Removes the
proc_fsinterface from the ACPI button driver.Signed-off-by Henrik Kretzschmar <[email protected]>---
you forgot to say why.....
First, because refering to /Documentation/feature-removal-schedule.txt it should be done:
Quoted 5 lines
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 <[email protected]>
Second, refering to /Documentation/feature-removal-schedule.txt
Quoted 5 lines
What: ACPI procfs interface When: July 2007 Why: After ACPI sysfs conversion, ACPI attributes will be duplicatedin sysfs and the ACPI procfs interface should be removed.
Who: Zhang Rui <[email protected]>
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 [email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 3 lines · Rui
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.
The last time I tried to remove this code,
we discovered that people were using it to query
the lid (button) status.
-Len
Quoted 18 lines
-----Original Message-----
From: Richard Hughes [mailto:[email protected]]
Sent: Thursday, July 12, 2007 6:26 AM
To: Zhang, Rui
Cc: Henne; Arjan van de Ven; Brown, Len; [email protected]; [email protected]; [email protected]
Subject: RE: [PATCH][ACPI][BUTTON] remove procfs-interfaceQuoted 3 lines · Rui
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.
Quoted 4 lines · Rui
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.
Quoted 1 line
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" ... :-)
Quoted 2 lines
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
Quoted 8 lines · Satyam Sharma
Quoted 4 lines · Rui
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.
Quoted 9 lines
Quoted 1 line
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.
Quoted 6 lines
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
Quoted 8 lines · Satyam Sharma
Quoted 4 lines · Rui
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.
Quoted 8 lines
Quoted 1 line
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.
Quoted 4 lines
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.
Signature · 6 lines
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)
Quoted 9 lines · Stefan Seyfried
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/acpiis 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