From: David Brownell <david-b@pacbell.net>
To: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: linux-pm@lists.osdl.org, Pavel Machek <pavel@ucw.cz>
Subject: Re: RE: on-ness
Date: Fri, 21 Apr 2006 12:00:45 -0700 [thread overview]
Message-ID: <200604211200.45959.david-b@pacbell.net> (raw)
In-Reply-To: <20060421183340.GA3071@isilmar.linta.de>
[-- Attachment #1: Type: text/plain, Size: 1959 bytes --]
> > Well, "on" could have one defined meaning. Maybe it's the only option
> > available, until drivers add intelligence. I don't see any problem
> > with the other names being system-specific, since it's rather unlikely
> > that a PCI_D3hot state will ever appear on most embedded ARM boxes.
> > And if any userspace code tries to set power states, it had darn well
> > better understand exactly what's going on.
>
> Yes. However if a network managing userspace code wants to set the power
> conusmption of a WLAN device to the lowest possible setting, it shouldn't
> need a configuration file specific for each platform.
The current wireless extensions have power management calls, and I'd
expect that whatever replaces them would do so as well. Which brings
out a point I've made before: userspace power management should not as
a rule be driven through /sys/devices/... files, but instead as part
of the normal API to the devices. That's the best way to ensure that
the operations fit into the devices' usage models, rather than as an
ill-fitting frankenstein bolt-on. ;)
> > That seems too complicated to me. When debugging, I want to visualize the
> > entire tree ... so I'd want a /sys/kernel/debug/clocktree file, with lots
> > of system-specific information. (Which gate bits are set/cleared? What
> > speeds? etc.) Or else I just want to know which state the driver is in,
> > like "mostly one". Some of that is taste, but also don't forget that each
> > attribute in sysfs has a cost.
>
> Uh, there's a rule "one-value-per-file" for sysfs. Arrays might be OK in
> certain cases, but lots of system-specific information in one file? No way,
> IMHO.
Remember that sysfs != debugfs, and /sys/kernel/debug is debugfs. Debugfs
explicitly allows seq_printf() and friends. (And for that matter, binary
data in sysfs is more than one-value-per-file ... there are plenty of cases
where that "rule" doesn't need to be obeyed.)
- Dave
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2006-04-21 19:00 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-18 18:39 RE: on-ness Brown, Len
2006-04-20 13:25 ` Pavel Machek
2006-04-21 15:27 ` David Brownell
2006-04-21 15:40 ` Dominik Brodowski
2006-04-21 17:03 ` David Brownell
2006-04-21 17:12 ` Dominik Brodowski
2006-04-21 18:30 ` David Brownell
2006-04-21 18:33 ` Dominik Brodowski
2006-04-21 19:00 ` David Brownell [this message]
2006-04-21 19:04 ` [OT] debugfs and sysfs [Was: Re: RE: on-ness] Dominik Brodowski
2006-04-21 19:01 ` RE: on-ness Pavel Machek
2006-04-24 21:04 ` David Brownell
2006-04-24 21:32 ` Pavel Machek
2006-04-24 23:21 ` David Brownell
2006-04-21 17:15 ` David Brownell
-- strict thread matches above, loose matches on Subject: below --
2006-04-21 17:58 Preece Scott-PREECE
2006-04-21 18:15 ` David Brownell
2006-04-24 21:32 Woodruff, Richard
2006-04-27 1:39 ` Patrick Mochel
2006-05-01 21:35 ` David Brownell
2006-04-27 14:12 Scott E. Preece
2006-04-27 17:01 ` Patrick Mochel
2006-05-01 21:58 ` David Brownell
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=200604211200.45959.david-b@pacbell.net \
--to=david-b@pacbell.net \
--cc=linux-pm@lists.osdl.org \
--cc=linux@dominikbrodowski.net \
--cc=pavel@ucw.cz \
/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