2007-05-23 17:39:56

by Nico Golde

[permalink] [raw]
Subject: maximum count of thermal zones and fans in acpi?

Hi,
I am currently implementing a general purpose shared library
for acpi focused on all the tools giving acpi information
like battery, thermal zones, fans, etc.

Since I was not able to find anything about it in the acpi
specs[0] (of course I didn't read every single page though)
and with a quick look into the kernel sources I wondered if
there is a maximum count for thermal zones and fans in the
acpi implementation of the kernel.

Every acpi module just calls proc_mkdir for example:
acpi_device_dir(device) = proc_mkdir(acpi_device_bid(device),
acpi_thermal_dir);

struct proc_dir_entry *proc_mkdir_mode(const char *name, mode_t mode,
struct proc_dir_entry *parent)
{
struct proc_dir_entry *ent;

ent = proc_create(&parent, name, S_IFDIR | mode, 2);
if (ent) {
ent->proc_fops = &proc_dir_operations;
ent->proc_iops = &proc_dir_inode_operations;

if (proc_register(parent, ent) < 0) {
kfree(ent);
ent = NULL;
}
}
return ent;
}

struct proc_dir_entry *proc_mkdir(const char *name,
struct proc_dir_entry *parent)
{
return proc_mkdir_mode(name, S_IRUGO | S_IXUGO, parent);
}


So is there no check for any max item count here?

I ask because I need to decide whether I want to allocate space for every
acpi object or to use a fixed size array for them depending on the maximum
item (where item is one device) count.

[0]: http://www.acpi.info/spec.htm

Kind regards
Nico
P.S. Please Cc me I am not subscribed

--
Nico Golde - http://ngolde.de - [email protected] - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.


Attachments:
(No filename) (1.76 kB)
(No filename) (189.00 B)
Download all attachments

2007-05-24 04:21:52

by Len Brown

[permalink] [raw]
Subject: Re: maximum count of thermal zones and fans in acpi?

On Wednesday 23 May 2007 13:07, Nico Golde wrote:
> Hi,
> I am currently implementing a general purpose shared library
> for acpi focused on all the tools giving acpi information
> like battery, thermal zones, fans, etc.

Note that /proc/acpi is going away in the long term.

The ideal is that things that are implemented via ACPI
should instead appear as generic features under sysfs
when possible.

There will still be some ACPI-specific things stuffed
into /sys/firmware/acpi -- but not the kind of useful-
to-the-user stuff that you are looking for.

> Since I was not able to find anything about it in the acpi
> specs[0] (of course I didn't read every single page though)
> and with a quick look into the kernel sources I wondered if
> there is a maximum count for thermal zones and fans in the
> acpi implementation of the kernel.
>
> Every acpi module just calls proc_mkdir for example:
> acpi_device_dir(device) = proc_mkdir(acpi_device_bid(device),
> acpi_thermal_dir);
>
> struct proc_dir_entry *proc_mkdir_mode(const char *name, mode_t mode,
> struct proc_dir_entry *parent)
> {
> struct proc_dir_entry *ent;
>
> ent = proc_create(&parent, name, S_IFDIR | mode, 2);

And this is a systematic bug in the ACPI code.
The "name" should _never_ be exposed to user-space.
Eg. all the names under, say /proc/acpi/*/*
are arbitrary strings created by the BIOS programmer.

They are meaningless to the user, except that they
are unique. To answer your question, there is no limit
to instances of ACPI objects, such as the number of thermal zones.

cheers,
-Len

> if (ent) {
> ent->proc_fops = &proc_dir_operations;
> ent->proc_iops = &proc_dir_inode_operations;
>
> if (proc_register(parent, ent) < 0) {
> kfree(ent);
> ent = NULL;
> }
> }
> return ent;
> }
>
> struct proc_dir_entry *proc_mkdir(const char *name,
> struct proc_dir_entry *parent)
> {
> return proc_mkdir_mode(name, S_IRUGO | S_IXUGO, parent);
> }
>
>
> So is there no check for any max item count here?
>
> I ask because I need to decide whether I want to allocate space for every
> acpi object or to use a fixed size array for them depending on the maximum
> item (where item is one device) count.
>
> [0]: http://www.acpi.info/spec.htm
>
> Kind regards
> Nico
> P.S. Please Cc me I am not subscribed
>