RE: Re: ACPI buttons in 2.6.12-rc4-mm2

RE: Re: ACPI buttons in 2.6.12-rc4-mm2

[Brown, Len]

I agree that the value of _LID can be usefult to user-space
and I'll be sure it is restored as a property of the lid device
under sysfs -- available as a simple file read like it
was under /proc.

thanks,
-Len


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: ACPI buttons in 2.6.12-rc4-mm2

[Bill Davidsen]

Brown, Len wrote:
> I agree that the value of _LID can be usefult to user-space
> and I'll be sure it is restored as a property of the lid device
> under sysfs -- available as a simple file read like it
> was under /proc.

You're missing the point, removing the /proc feature breaks existing 
code. You can add new features in /sys as you like, but when you remove 
existing featires you break system for no benefit.

RE: ACPI buttons in 2.6.12-rc4-mm2

[Brown, Len]

 
>> I'm open to suggestions on how to approach this transition.
>> I can make ACPI_PROC a static build option -- what else
>> can I do to ease the transition in this, our stable release?
>
>Well I don't know how awkward this would be from an 
>implementation POV, but can we just leave the legacy
>/proc stuff there until the /sys interface is
>all in place and userspace is upgraded?
>Then kill all the /proc stuff later?
>
>We could also print a rude message the first time someone 
>tries to use a deprecated /proc file, just to help push the
>userspace tool developers along.
>Although I note that sys_bdflush() is still with us ;)

/proc/acpi/event
/proc/acpi/sleep
are used the most.

/proc/acpi/<drivername>/<BIOS devname>/* are really screwed up
in that <BIOS devname> is an arbitrary internal BIOS string
that should have never been exposed to userspace.  Instead
we should have done what sysfs does -- look at the _type_
of device and then simply add a number to it -- cpu0, cpu1
so that a program could actually find stuff.

I'm constantly nagged that this layer in the /proc/tree
had arbitrary strings in pathnames.  Also, the /proc
file handling code is buggy -- so it wastes my time
maintaining it, when it should not exist at all...
Restoring the /proc code to the button driver will
increase button.c in size by over 60%...

So I'm in favor of whatever solution makes it all go away
as soon as possible.

-Len


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

RE: ACPI buttons in 2.6.12-rc4-mm2

[Brown, Len]

>Len Brown <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
>> I deleted /proc/acpi/button on purpose,
>> did you have a use for those files?
>
>Can we put it back, please?

of course.

>We cannot go ripping out stuff which applications and users 
>are currently using without quite a lot of preparation.

Agreed.  Although the implementation of the /proc lid status
file is fundamentally flawed in that even its name in /proc
is able to change and thus it is a totally bogus user-space API,
it was not thoughtful to delete it.

I'm open to suggestions on how to approach this transition.
I can make ACPI_PROC a static build option -- what else
can I do to ease the transition in this, our stable release?

thanks,
-Len


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: ACPI buttons in 2.6.12-rc4-mm2

[Andrew Morton]

"Brown, Len" <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
>
> 
> >Len Brown <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
> >> I deleted /proc/acpi/button on purpose,
> >> did you have a use for those files?
> >
> >Can we put it back, please?
> 
> of course.

Thanks.

> >We cannot go ripping out stuff which applications and users 
> >are currently using without quite a lot of preparation.
> 
> Agreed.  Although the implementation of the /proc lid status
> file is fundamentally flawed in that even its name in /proc
> is able to change and thus it is a totally bogus user-space API,
> it was not thoughtful to delete it.
> 
> I'm open to suggestions on how to approach this transition.
> I can make ACPI_PROC a static build option -- what else
> can I do to ease the transition in this, our stable release?

Well I don't know how awkward this would be from an implementation POV, but
can we just leave the legacy /proc stuff there until the /sys interface is
all in place and userspace is upgraded?  Then kill all the /proc stuff
later?

We could also print a rude message the first time someone tries to use a
deprecated /proc file, just to help push the userspace tool developers
along.  Although I note that sys_bdflush() is still with us ;)



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: ACPI buttons in 2.6.12-rc4-mm2

[Len Brown]

On Sun, 2005-05-22 at 07:25 -0400, Cameron Harris wrote:
> I just upgraded from 2.6.11.3 and now my /proc/acpi/button directory
> doesn't exist...

I deleted /proc/acpi/button on purpose,
did you have a use for those files?

Note that over time everything in /proc/acpi is
going away.  In this case, there didn't seem to be
a case for making appear in /sys.

thanks,
-Len




-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: ACPI buttons in 2.6.12-rc4-mm2

[Matthew Garrett]

Len Brown <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:

> I deleted /proc/acpi/button on purpose,
> did you have a use for those files?

There are various cases where it's useful to know whether a laptop is
shut or not, and /proc/acpi/button seems to be the only place where that
information is made available at the moment.

-- 
Matthew Garrett | mjg59-chiark.mail.linux-rutgers.kernel-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: ACPI buttons in 2.6.12-rc4-mm2

[Andrew Morton]

Len Brown <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
>
> On Sun, 2005-05-22 at 07:25 -0400, Cameron Harris wrote:
> > I just upgraded from 2.6.11.3 and now my /proc/acpi/button directory
> > doesn't exist...
> 
> I deleted /proc/acpi/button on purpose,
> did you have a use for those files?

Can we put it back, please?

> Note that over time everything in /proc/acpi is
> going away.  In this case, there didn't seem to be
> a case for making appear in /sys.

That'll be hard.  I guess we could add the new /sys entries, make sure that
userspace tool developers have migrated and then remove the /proc entries
in a year or so.

We cannot go ripping out stuff which applications and users are currently
using without quite a lot of preparation.


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf