Advice on APM-EMU reunion

Hello,

some months ago I sent to the MIPS and ARM mail lists a patch to unify the several APM emulation codes adding a new dedicated directory so it can be used to put there the per board specific code avoiding code duplications (see files ./arch/arm/kernel/apm.c, ./arch/mips/kernel/apm.c and ./arch/sh/kernel/apm.c that are almost the same).

The patch is here "http://www.linux-mips.org/archives/linux-mips/2006-07/msg00144.html" and it has been lost in the deep space...

The target is to remove the files ./arch/{arm,mips,sh}/kernel/apm.c and to add files drivers/apm-emu/{Kconfig,Makefile,apm-emu.c}.

Now I try on this list in order to have some advice if this could be a good idea and what about if I add a new class "apm_emu" on the sysfs support with proper registrations functions.

Thanks in advance,

Rodolfo

GNU/Linux Solutions                  e-mail:    [email protected]
Linux Device Driver                             [email protected]
Embedded Systems                     		[email protected]
UNIX programming                     phone:     +39 349 2432127

I'm not sure this is a good idea. As you're creating a new interface, why not create something new/improved without the problems that confining yourself to APM emulation brings?

Regards,

Richard

Because several applications (and expecially in embedded systems) use that interface. However adding a sysfs support I try to define a new (and most versatile) interface.

Ciao,

Rodolfo

GNU/Linux Solutions                  e-mail:    [email protected]
Linux Device Driver                             [email protected]
Embedded Systems                     		[email protected]
UNIX programming                     phone:     +39 349 2432127

Not quite, the rationale for it being dropped was here:

http://article.gmane.org/gmane.linux.kernel/485831

However, it has since been reposted:

http://article.gmane.org/gmane.linux.kernel/485833
http://article.gmane.org/gmane.linux.kernel/485834
http://article.gmane.org/gmane.linux.kernel/485835
http://article.gmane.org/gmane.linux.kernel/485837

and merged back in to -mm. This is all post 2.6.20 stuff, though..

Not quite. I had asked Rudolfo to unify the two copies of APM who then went silent, so I went and my own thing until Rudolfo eventually reappeared with his own patch. So all the recent discussion was about my patch.

Ralf

Ok, starting from these patches I'd like to add a "battery support" to the kernel.

What I suppose to do is a new class with a proper methods useful to collect several info on battery status, such as get_ac_line_status() get_battery_status(), get_battery_flags(), get_remaining_battery_life() and so on.

The output will be APM-like into file "/proc/apm" (one line per battery, or just the "main"/first one?) so that existing applications continue to work and under sysfs into "/sysfs/class/battery".

Is it sane? :)

Thanks in advance,

Rodolfo

GNU/Linux Solutions                  e-mail:    [email protected]
Linux Device Driver                             [email protected]
Embedded Systems                     		[email protected]
UNIX programming                     phone:     +39 349 2432127

Wasn't there recently a big discussion on lkml about a battery class?

Matt

APM-EMULATION: apm_get_power_status() should be NULL on init.

---

If the function apm_get_info() do like this:

static int apm_get_info(char *buf, char **start, off_t fpos, int length)

   {
           struct apm_power_info info;
           char *units;
           int ret;

           info.ac_line_status = 0xff;
           info.battery_status = 0xff;
           info.battery_flag   = 0xff;
           info.battery_life   = -1;
           info.time           = -1;
           info.units          = -1;

           if (apm_get_power_status)
                   apm_get_power_status(&info);

...

we shouldn't set:

   static void __apm_get_power_status(struct apm_power_info *info)
   {
   }

   void (*apm_get_power_status)(struct apm_power_info *) = __apm_get_power_status;

otherwise the check is not needed. Furthermore setting the function to NULL signals that the apm-emulation layer is not already assigned (I found this very useful for my apm-emulation battery_class support).

Hi!

Yep. Notice that designing /sysfs/class/battery is not going to be easy, and that some work was already done in context of olpc project. Search the mailing lists...
Pavel

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html