From: Len Brown <lenb@kernel.org>
To: Nico Golde <nico@ngolde.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: maximum count of thermal zones and fans in acpi?
Date: Thu, 24 May 2007 00:20:19 -0400 [thread overview]
Message-ID: <200705240020.19925.lenb@kernel.org> (raw)
In-Reply-To: <20070523170702.GA9169@ngolde.de>
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
>
prev parent reply other threads:[~2007-05-24 4:21 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-23 17:07 maximum count of thermal zones and fans in acpi? Nico Golde
2007-05-24 4:20 ` Len Brown [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200705240020.19925.lenb@kernel.org \
--to=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nico@ngolde.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox