[Toybox] [PATCH] acpi: change when to recurse

[Isaac Dunham]

On Sun, Oct 05, 2014 at 04:28:21PM -0500, Rob Landley wrote:
> On 10/04/14 15:52, Isaac Dunham wrote:
> > acpi: never follow symlinks, always recurse in dirs.
> > 
> > /sys/class contains several directories, each containing symlinks to
> > devices of a given type.
> > The symlinks are where we want to end recursion.
> > This makes for a simpler, cleaner, and more correct check, avoids needless
> > recursion, and shrinks the text segment by 25 bytes (at least here).
> 
> I _totally_ got bit by this doing mdev back on busybox... repeatedly:
> 
> http://lists.busybox.net/pipermail/busybox/2006-February/052297.html
> http://lists.busybox.net/pipermail/busybox/2008-July/066210.html
> 
> I.E. things that were directories can become symlinks, and vice versa.
> I'm reluctant to trust it.

Ok, thanks for the warning.
Is there a simple function to check absolute depth?
(ie, how many dirs down from / the current dirtree entry is)
I *really* hate the first way I wrote; it's not even a magic number, it's
a disgusting hack that *will* break if it ever gets called outside 
/sys/class/power_supply/.  And it certainly can't be copied for if we
recurse through /sys/class/thermal and /sys/class/power_supply.

If there isn't a ready-to-go solution, I've got some code I could drop
in that counts how many times a given char occurs; get the path and
count the directory separators, and we know how deep we are.

> > --
> > I noticed that this approach was possible while poking around thinking
> > about a possible Busybox port, plotting to add -c and -t, and experimenting
> > with using nftw.
> > 
> > acpi -c seems to be fairly simple:
> 
> I have no idea what acpi -c or -t are supposed to _do_, and you don't
> say here.
Sorry about that.

acpi options that are likely to be of interest to some people:
 -a  show ac adapter status
 -b  show battery status
 -c  show cooling device status
 -t  show temperature
(-V  show everything we support)

All of them are useful to some degree for me.
> >   recurse through /sys/class/thermal,
> >   read type, max_state, and cur_state,
> >   if max_state and cur_state were unreadable,
> >     printf("Cooling %d: %s no state information available\n", ctr++, type)
> >   else printf("Cooling %d: %s %d of %d\n",ctr++,type,cur_state, max_state)
> > 
> > It would be rather difficult to do this in the same callback as -ab.
> 
> Not knowing what -ab do, i think I'll have to re-reply to this message
> when I have time to dig through the code and see what the existing one
> does...

recurse through /sys/class/power_supply and read a few different files.

> 
> > The above method does ignore quite a few sensors;
> > there's no obvious way to get HDD temps besides these commands:
> >  smartctl -A -d ata /dev/sda |grep Temperature
> > # or (Hitachi-only, but no spin-up)
> >  hdparm -H /dev/sda
> 
> strace, the breakfast of champions.

Yes, I've tried that and ltrace.
hdparm calls ioctl(fd, SG_IO, ...) with a very large struct that I haven't
figured out.
And no, it's not something where you can just point it at an empty
buffer (I tried that already).

> > Then also Thinkpads have multiple sensors, which are apparently named 
> > (in sysfs) temp*_input
> > The "official" acpi misses both the Thinkpad sensors and HDD sensors.
> 
> If you have the testing environment, by all means let's get this right.

> Query: what are you trying to _do_?

Read temperatures (and perhaps cooling device state, but I can usually hear
that well enough...)

Here, I've got three computers that I usually consider available for
testing:
-"newbook", a very old Atom N270-based Acer Aspire One netbook.
Main system at present. Currently runs a couple musl-based distros,
with Sid, SL 5, and Jaunty installs present.
I assume you wouldn't care about testing on FreeDOS, which I also have
installed. ;)
(Atom N270 at 1.6 GHz, 1 gig RAM)

-"Caracal", a dual-core Thinkpad X100e suffering from chronic overheating
problems. Rarely use for prolonged periods. Runs Debian (Squeeze/ Sid
from when it meant ~Jessie); mainly used for CDE/Motif stuff.
(AMD Neo at 1.6 GHz; 2 gigs RAM)

-a cheapo armv6 Android Gingerbread phone with a real keyboard, Qualcomm
Adreno graphics and a 240x320 pixel screen; rooted with a third-party rom.
(QCT MSM7x27 SURF, nominal ~600 MHz; 256 megs ram)

I have a fourth system available as well (a turn-of-the-millenium Dell
with a PIII at 800 MHz and 256 megs RAM), but rarely use it.
I keep it around partly because it's the only system I have with a CD
drive, and partly because it can run eComStation 1.x (post-IBM OS/2)
or Linux 2.4.x (Feather, DSL, etc) from livecd.

So yes, I do have the environment for testing.


Thanks,
Isaac Dunham

 1412568789.0