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

[Rob Landley]

On 10/05/14 23:13, Isaac Dunham wrote:
> 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 just recurse on the node's parent pointer are count up until I hit the
null at the top. (Haven't bothered to make a function for it, it's a
simple for loop.)

This doesn't tell you how far you are from /, it tells you how far you
are from the top directory you started recursing from. (Which could be a
path arbitrarily deep from root, but is generally a known quantity.)

I'm poking at an mdev rewrite and that uses this, for the same reason.
(Descending into /sys and the layout is magic, behavior changes based on
how many levels down you went.)

> 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.

What are the actual rules? What are you looking for in the filesystem?

> 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.

We have a tree structure with one node per directory level, while you
can make a path from it via dirtree_path(), you usually don't need to.

>>> --
>>> 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

--help implies it's currently doing those two already.

>  -c  show cooling device status
>  -t  show temperature
> (-V  show everything we support)

Ok.

> All of them are useful to some degree for me.

Indeed.

>>>   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.

My LCD has a cooling device? Really?

Ok, it's got a max state of 9 and a cur state of 0. Meaning...?

(Devices 0 and 1 are both "Processor" and cur_state 0, one has max state
of 3 the other 10.)

So... yay thermal. That's easy to recurse on, but all we do is print out
the numbers?

(And yes, give it its own dirtree callback function. If !parent then
recurse following symlinks, otherwise openat() cur_state max_state and
type relative to dirtree_parentfd().)

>>> 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.

SG_IO sounds like it's sending its own scsi command. Possibly:

http://www.t10.org/lists/2op.htm

I can dig down into the kernel and try to reverse engineer it... Ah,
there's docs:

http://tldp.org/HOWTO/SCSI-Generic-HOWTO/sg_io.html
http://tldp.org/HOWTO/SCSI-Generic-HOWTO/pexample.html

Lots of docs:

http://sg.danny.cz/sg/sg_io.html

SCSI is a mostly standardized packet protocol for talking to hard
drives. What the packets travel over is irrelevant these days. When IDE
became "ATA" it basically grabbed a subset of the scsi protocol, and
these days USB disks are using SCSI packets, SATA is more or less
overclocked gigabit ethernet PHYS sending SCSI packets to and from a
drive over expensive mutant cat5. There are crazy people doing SCSI over
ethernet, for no readily apparent reason. (Just do a network block
device already, you don't need to export bus level information over a
network. There is no POINT to doing that...)

P.S. "SAS" or "Serial Attached SCSI" is SATA with a bigot tax. For
people who think SCSI is superior to all else (back when an obsolete
version of this protocol went over specific types of hardware that
became obsolete in about 1985), they gold plate the connectors and spin
the disks twice as fast (so they wear out faster) and charge people
about 10 times as much money for the exact same electronics. Dell LOVED
selling this stuff to people because the money just LEAPED right off
these idiots and into Dell's pockets...

(Oh, hilarious bit. They'd put two "we do not admit this is ethernet"
jacks on each disk and claim that dual pathing to the controller somehow
increased reliability of the drive because obviously the solid state
eletronics were more likely to fail than the MOVING PARTS of the disk.
As I said, more money than sense...)

> And no, it's not something where you can just point it at an empty
> buffer (I tried that already).

Nah, this is a bit like ping putting together its own low level packet
using the raw interface and having to do its own headers. You're
assembling a SCSI packet telling the hard drive to return a reply
packet, and then parsing the returned packet.

There are standard scsi commands for basic status info, which are
repeated in a bunch of places (such as the wikipedia page about scsi).

>>> 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...)

Let's start with the thermal one you listed first. I apparently have the
stuff to test that here, and it seems really simple.

Thinkpads, I haven't got anymore. (About ten years ago I had more than
one. But I haven't bought one since before they sold the line to lenovo.)

> Here, I've got three computers that I usually consider available for
> testing:
> -"newbook", a very old Atom N270-based Acer Aspire One netbook.

Aspire 722 here. My D255e got stolen. :(

Crappy AMD processor in it, but upgradeable to 8 gigs (the atoms maxed
out at 2 because they only did 32 I/O address pins and they needed to
reserve some I/O memory for device mappings and it's all powers of 2.
Faster processor but the memory got CRAAAAAMPED. 8 gigs is just about
tolerable, combined with the portability of the machine...)

> Main system at present. Currently runs a couple musl-based distros,
> with Sid, SL 5, and Jaunty installs present.

I'm still just using xubuntu. It was there. (Everything else is in a
chroot.)

> 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 should actually root my phone. I still haven't bothered. (I use it as
a phone. Ok, and a twitter reader. And portable tower defense game.)

> 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.

I actually blew a noticeable amount of money on a real laptop last year,
system76 8x modernish processor (i5? i7? one of them. Probably not REAL
8x, I think it's hyper-threaded, but still) and 16 gigs ram.

Mild overheating problem, but it can build all the aboriginal targets
(simultaneously, in parallel) in like 3 hours, as opposed to the 24
hours my netbook takes.

That would actually be a fun thing to try thermal sensor stuff on,
because the reason I iknow it has an overheating problem is dmesg says
"thermal limit reached, processors throttled" when I leave it doing a 3
hour build.

Hmmm...

$ ls /sys/class/thermal
cooling_device0  cooling_device3  cooling_device6  thermal_zone0
cooling_device1  cooling_device4  cooling_device7
cooling_device2  cooling_device5  cooling_device8

$ ls /sys/class/thermal/thermal_zone0
device  passive  power      temp               trip_point_0_type  uevent
mode    policy   subsystem  trip_point_0_temp  type

$ cat /sys/class/thermal/cooling_device*/type
Processor
Processor
Processor
Processor
Processor
Processor
Processor
Processor
LCD

All the "Processor" entries are 0 3, and the LCD is 7 7. (For some
reason the LCD's cur state and max state are the same, even though the
lid's open and the display is off. Odd.)

Rob

 1412573768.0