apmd and other archs

[Hadess]

Quoting Michael Schmitz <schmitz at 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/