inconsistency in /proc/acpi directory structure?

inconsistency in /proc/acpi directory structure?

[Nico Golde]

[-- Attachment #1: Type: text/plain, Size: 1587 bytes --]

Hi,
I wrote some shared library to get ACPI values for user 
space acpi tools and came to a problem.

I check if an ACPI feature exists by checking for its 
directory, e.g. /proc/acpi/fan.

The problem with this is, that this gets created when the 
specific module is loaded, so if you load the module but 
your system does not support it properly you get an empty 
directory.

But even checking for an empty directory is not enough since 
there comes ibm-acpi (maybe others).

With working fan and usage of ibm-acpi you also get an empty 
/proc/acpi/fan dir because you have /proc/acpi/ibm/fan where 
you can then find the relevant files.
This sucks, I mean I can implement a workaround for this, 
but if asus-acpi would do the same and maybe others would 
exists I have to check alot of directories. So why not using 
the existing directory structure?

I am not sure if this is a bug in ibm-acpi or an 
inconsistency in the kernel since to me it is not obvious to 
just create the directory in module modprobing, why not 
doing it when dumping the first data to a file?

Why is ibm-acpi not using the existing directory structure 
(also wrote to the ibm-acpi guys but with no answer so far, 
so I try to get answers here)? Do I miss anything?


I hope this is the right list for my questions, please point 
me to the right direction if not.
Kind regards
Nico
P.S Please Cc me, I am not subscribed.

-- 
Nico Golde - http://ngolde.de - nion@jabber.ccc.de - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: inconsistency in /proc/acpi directory structure?

[Henrique de Moraes Holschuh]

On Thu, 09 Aug 2007, Nico Golde wrote:
> But even checking for an empty directory is not enough since 
> there comes ibm-acpi (maybe others).

As far as ibm-acpi goes, you can do me a BIG favour, and pretend it has
nothing in procfs.

> With working fan and usage of ibm-acpi you also get an empty 
> /proc/acpi/fan dir because you have /proc/acpi/ibm/fan where 
> you can then find the relevant files.
> This sucks, I mean I can implement a workaround for this, 
> but if asus-acpi would do the same and maybe others would 
> exists I have to check alot of directories. So why not using 
> the existing directory structure?

[...]

> Why is ibm-acpi not using the existing directory structure 
> (also wrote to the ibm-acpi guys but with no answer so far, 
> so I try to get answers here)? Do I miss anything?

I did reply to you. Hmm... I will resend the reply just in case, I have no
idea why it didn't reach you.

I didn't expand a lot on this email because I replied in detail to you on
the email you didn't receive.  I will resend it to this thread as well.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: inconsistency in /proc/acpi directory structure?

[Henrique de Moraes Holschuh]

(here's the email I sent Nico but which didn't arrive anywhere. CCs/BCCs
added to resend it to everyone)

On Mon, 06 Aug 2007, Nico Golde wrote:
> I recently implemented libacpi (http://www.ngolde.de/libacpi.html)
> to have some kind of provider for all these acpi applets out 
> there. What makes me wonder is that people using this lib 
> and ibm-acpi complain about broken fan support.

Well, this is all going to be handled by libsensors quite soon, because
AFAIK all of the fan and thermal monitoring in the kernel is going to switch
to the hwmon class as fast as we can manage.

Thinkpad-acpi and most other laptop drivers have already made the move, and
the ACPI subsystem itself is also doing it.

For thinkpad-acpi, use of procfs for thermal and fan monitoring and control
is heavily deprecated and will go away as soon as I possible can get away
with it.  I would be very happy to see it gone, the thinkpad-acpi procfs
code has been nothing but grief to me to maintain, so far.

I won't hate you for using thinkpad-acpi procfs in your library, but I don't
want to hear of crap like the one some applets out there pulled on ibm-acpi
ever again.  So, please either don't use procfs to talk to thinkpad-acpi, or
do it right.

That happens because thinkpad-acpi's procfs interface is, frankly, a piece
of crap that can be a lot of hassle to work with from an userspace
application's point-of-view.  You'll need to parse its key: value records
into data structures, and find out the one you need.  You will have to look
at the kernel code (or ask me) to know all possible return values of a given
key, etc.  If you go the easy way like gnome sensors-applet did, for
example, it *will* *break* sooner or later.

In fact, just to make it clear, I am asking you to please *not* support
/proc/acpi/ibm in your libacpi. 

You are welcome to use the new sysfs interfaces from thinkpad-acpi, which is
much better documented and easier to use.  That said, IMO your efforts would
be much better spent helping libsensors, as any lib interfacing to
thinkpad-acpi to get fan and thermal data is just duplicating the effort of
libsensors.  HAL is probably in the picture as well, since your target
demographics seems to be desktop environment applets.

> If looking at their /proc/acpi it looks like /proc/acpi/fan 
> is empty and the fan information can be found in a seperated 
> ibm directory.

Yeah. /proc/acpi/fan is for the ACPI subsystem generic ACPI fan support.  No
other driver will mess with it, and it has its own syntax that is in no way
tied to whatever thinkpad-acpi uses in its procfs interface, for example.

> Now this makes it very hard to support ibm-acpi and I guess 
> it is the same for asus4acpi. Why does the kernel create an 
> empty directory instead of none here? And why doesn't 
> ibm-acpi extend the original /proc/acpi structure apart from 
> ibm specific feature stuff?

Well, apparently you require more up-to-date knowledge on how these things
connect together to do a good job.  May I suggest you go over the linux-acpi
mailinglist archives for 2007?  And also the lm-sensors developer
mailinglist archives, so that you get to know hwmon and libsensors better?
And also reading all the kernel 2.6.22 and 2.6.23-rc* ACPI documentation?
That will give you a better picture of what is happening.

Unfortunately, there is no easy, complete documentation for this.  As usual,
it is in the code and the mailing-lists.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: inconsistency in /proc/acpi directory structure?

[Len Brown]

Hi Nico,
I have to second what Henrique wrote.
Please avoid /proc/acpi/* whenever you can can.
We are trying to get rid of it completely,
but that is only partly done.

I really resist changes to /proc/acpi/* because
I consider it legacy and would rather the effort
be focused on the new sysfs interfaces.

cheers,
-Len

Re: inconsistency in /proc/acpi directory structure?

[Nico Golde]

[-- Attachment #1: Type: text/plain, Size: 948 bytes --]

Hi,
* Len Brown <lenb@kernel.org> [2007-08-09 19:25]:
> I have to second what Henrique wrote.
> Please avoid /proc/acpi/* whenever you can can.
> We are trying to get rid of it completely,
> but that is only partly done.

I know about that and it's a typical kernel hacker argument, 
but don't forget people want to have working software in the 
meantime of your switch ;)

> I really resist changes to /proc/acpi/* because
> I consider it legacy and would rather the effort
> be focused on the new sysfs interfaces.

I will switch step by step. From what I can see not really 
much things apart from the acpi version already switched to 
sysfs. Maybe I missed it. I will answer in detail on 
Henriques mail hopefully tomorrow.
Kind regards and thanks for your quick replies
Nico
-- 
Nico Golde - http://ngolde.de - nion@jabber.ccc.de - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: inconsistency in /proc/acpi directory structure?

[Len Brown]

On Thursday 09 August 2007 13:45, Nico Golde wrote:
> Hi,
> * Len Brown <lenb@kernel.org> [2007-08-09 19:25]:
> > I have to second what Henrique wrote.
> > Please avoid /proc/acpi/* whenever you can can.
> > We are trying to get rid of it completely,
> > but that is only partly done.
> 
> I know about that and it's a typical kernel hacker argument, 
> but don't forget people want to have working software in the 
> meantime of your switch ;)
> 
> > I really resist changes to /proc/acpi/* because
> > I consider it legacy and would rather the effort
> > be focused on the new sysfs interfaces.
> 
> I will switch step by step. From what I can see not really 
> much things apart from the acpi version already switched to 
> sysfs. Maybe I missed it. I will answer in detail on 
> Henriques mail hopefully tomorrow.
> Kind regards and thanks for your quick replies

Things which have switched are now under CONFIG_ACPI_PROCFS in 2.6.23.
When more things switch in the future, they'll go there too.

If you have a specific suggestion for a bug fix to /proc/acpi/*,
please let me know, or better yet, send a patch.

-Len