and it implements /proc/apm for battery infos, but the infos there are

That part was actually fairly easy IIRC (did that for 2.2.19).

Well, the 2400/3400/3500 is not so easy, especially without the
floats in kernel ;) I'd be glad to have some testers with these
machines to tell me if /proc/pmu & /proc/apm say sensible things
about their batteries, and eventually compare against what Batmon
or gkrellm-pmu says.

less detailed that what pmud or the new /proc/pmu provides (the APM
API is quite simplistic).

/proc/pmu isn't in 2.4.7-pre3 ... I guess I need to try your tree once
again (Paulus' has the new MMU context code that completely breaks MOL,

that's another reason to switch back).

MOL has been fixed for some time now ;) The new MMU context code
is in my tree as well, and I think in bk _2_4 now. Get the latest
MOL rsync/bk tree.

I don't think anything as PC centric as apmd has room here, but I may
be wrong as I didn't look at it.

I'll ask the apmd maintainer to remove m68k and powerpc from the

architecture list in the absence of complete APM support then.

Yup. I need to look at what apmd does and if it makes sense to
provide support for it or not, but in the meantime, there's
probably no need for it. That should be confirmed however.
Ben.

OK, it seems fair for me to resume my work on pmud then. I wasn't sure
if pmud was going to stick around if your apm emulation was complete
enough. I reckon we still need pmud because we're just different ;)

For the record, and so that people can give some feedback, after
receiving a new iBook, I resumed the work on libapm4pmud. It allows to
recompile quite a few applets/docklets/whatever battery monitors that
would only run on x86 otherwise, without any code change.

I'm also working on switching pmud to use a unix socket instead of a
internet socket which should speed it up quite a bit.

Michael, do you think that libapm4pmud could find its place in a
pmud-dev package or such ?