linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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/

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