From: Hadess <hadess@writeme.com>
To: Michael Schmitz <schmitz@zirkon.biophys.uni-duesseldorf.de>
Cc: Avery Pennarun <apenwarr@worldvisions.ca>,
Michael Schmitz <schmitz@opal.biophys.uni-duesseldorf.de>,
Hadess <hadess@writeme.com>,
debian-powerpc@lists.debian.org, linuxppc-dev@lists.linuxppc.org
Subject: Re: apmd and other archs
Date: Thu, 23 Nov 2000 14:36:21 +0100 (MET) [thread overview]
Message-ID: <974986581.3a1d1d55698b0@imp.free.fr> (raw)
In-Reply-To: <Pine.LNX.4.10.10011231200590.18581-100000@zirkon.biophys.uni-duesseldorf.de>
Quoting Michael Schmitz <schmitz@zirkon.biophys.uni-duesseldorf.de>:
> > > The info logged to /proc/apm is currently logged to /etc/power/apm.
> I have
> >
> > Is this a typo? Why is status information in /etc?
>
> Because user space pmud can't create /proc/ entries?
>
> > > no idea what /dev/apm does aside from providing that log info, and I
> have
> > > no clue what /dev/apm_bios does, either. There should be no major
> problems
> >
> > The /dev device selects true for read() when a power event happens
> (such as
> > a user suspend request or battery status change) and can be written to
> allow
> > a user process to initiate a system suspend.
>
> We use a TCP port on the loopback interface for that.
>
> > > independent. I just don't see a good reason to change from pmud to
> apmd,
> > > if that's what you're suggesting.
> >
> > It's always better, IMHO, to keep Linux userspace as similar as
> possible
>
> Granted, if that doesn't place a high burden on the kernel code. I
> thought
> 'keep it simple, stupid' was the kernel motto?
>
> > between different architectures. If pmud has features that apmd
> doesn't
> > have, or vice versa, I would rather merge them than keep them
> separate. In
> > the process, we might as well work on making the kernel interfaces
> similar
> > too. That's the whole _point_ of the kernel.
>
> I beg to differ. The whole point of the kernel is to separate critical
> code and architecture dependant things from user space. It's not about
> making interfaces as similar as possible. If the hardware is
> sufficiently
> different, a different kernel interface is OK. That's why no one
> implemented a VGA compatibility layer in the kernel for PPC, m68k and a
> few other archs.
>
> It all boils down to: how generic is the apm interface?
Hi,
Seems like I missed a good part of the discussion... First reason I wanted apmd
marked as x86 only, is because it is useless _now_ on power-pc. We have a PMU,
not an APM BIOS (ugh!), we have pmud not apmd. What is the point compiling it
for powerpc if it's not working and will probably never ?
We have here a big fat hardware difference. A PMU's a PMU, and an APM BIOS's an
APM BIOS. I'm now working (with help from Joseph Garcia) on an APM library for
PMUD. It hides PMUD from the libapm-using battery applets. I posted last week a
first "socket" version that uses the TCP socket on the loopback interface to get
its information. And I could compile some programs from the apmd distribution
and battstat with it.
I'm working right now on 1) Debugging socket version, 2) Implementing a version
getting its info from /etc/power/apm (soon to be moved, better tell Stephan I
guess), 3) Implement the rest of the functions from the apm library (like sleep
and everything...)
IMHO, an apm interface in the kernel would be "evil", that's a (simple)
userspace job.
Cheers
/Hadess
http://hadess.net
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2000-11-23 13:36 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20001122143042.A28078@worldvisions.ca>
2000-11-23 8:47 ` apmd and other archs Michael Schmitz
2000-11-23 10:09 ` Avery Pennarun
2000-11-23 10:40 ` Michel Dänzer
2000-11-23 11:08 ` Avery Pennarun
2000-11-23 11:15 ` Michael Schmitz
2000-11-23 11:31 ` Avery Pennarun
2000-11-23 13:36 ` Michael Schmitz
2000-11-23 14:18 ` Gabriel Paubert
2000-11-23 18:40 ` Michael Schmitz
2000-11-24 14:23 ` Gabriel Paubert
2000-11-24 18:29 ` Takashi Oe
2000-11-24 14:47 ` Olaf Hering
2000-11-24 15:23 ` Michael Schmitz
2000-11-23 11:37 ` Gabriel Paubert
2000-11-23 13:32 ` Tony Mantler
2000-11-23 14:12 ` Gabriel Paubert
2000-11-23 14:24 ` Adrian Cox
2000-11-24 10:07 ` Gabriel Paubert
2000-11-24 2:42 ` Josh Huber
2000-11-23 11:11 ` Michael Schmitz
2000-11-23 13:36 ` Hadess [this message]
2000-11-23 13:54 ` Michael Schmitz
2000-11-27 13:23 ` Michael Schmitz
2000-11-27 14:53 ` Benjamin Herrenschmidt
2000-11-27 15:34 ` Michael Schmitz
2000-11-27 20:50 ` Michael Schmitz
2000-11-24 13:51 ` Benjamin Herrenschmidt
2000-11-24 15:11 ` Bastien Nocera
2000-11-24 13:40 ` Benjamin Herrenschmidt
2000-11-24 14:29 ` Gabriel Paubert
2000-11-24 15:33 ` Benjamin Herrenschmidt
2000-11-24 16:26 ` Gabriel Paubert
2000-11-24 17:31 ` Benjamin Herrenschmidt
2000-11-24 17:56 ` Geert Uytterhoeven
2000-11-24 19:27 ` Gabriel Paubert
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=974986581.3a1d1d55698b0@imp.free.fr \
--to=hadess@writeme.com \
--cc=apenwarr@worldvisions.ca \
--cc=debian-powerpc@lists.debian.org \
--cc=linuxppc-dev@lists.linuxppc.org \
--cc=schmitz@opal.biophys.uni-duesseldorf.de \
--cc=schmitz@zirkon.biophys.uni-duesseldorf.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;
as well as URLs for NNTP newsgroup(s).