APMD-List:
Archives

  From: Craig Markwardt <craigm@pcasun3.gsfc.nasa.gov>
  To  : <apmd-list@worldvisions.ca>
  Date: Mon, 28 Sep 1998 21:10:59 -0400 (EDT)

apmlib issues

 > Yup.  The problem we have to deal with is that kernel APM support can be
 > present even if the apmd daemon isn't running.  Worse, the apm command might
 > be executed without apmd being present.

Hmm.  That is a problem.  Can apm check for the existence of apmd?

Such activity could be put into the kernel.  I don't know enough about
the kernel to know how much logic has to go into flushing the buffers. 

 > But if the kernel calls the APM bios too much, then I can imagine a
 > denial-of-service (or disruption-of-service) attack like this:
 > 
 > 	while :; do cat /proc/apm >/dev/null; done
 > 
 > If that causes problems when run as a user, the kernel needs to be fixed.
 > (eg. call the APM bios a maximum of once per second or something, caching
 > results in the meantime)

Yes, I could see that too.  I found that running your command
continuously created a noticeable effect on one of my laptops (the
mouse cursor would get jittery, etc).  The system wasn't totally
*killed*.  My kernel version caches most of the information, but some
of it can't be reliably cached (things like display status).

 > > * The apm_read functionality could be more flexible.  Currently only
 > >   the APM bios device can be select()'ed.  It would be nice to be able
 > >   to separate the select and the read, so that a program could keep
 > >   track of other file descriptors.  For example, a more intelligent
 > >   power manager daemon might need this.
 > 
 > I don't see a problem.  Just manually select() on the fd returned from
 > apm_open (and any others you might want), then call apm_get_events if your
 > APM fd is ready.  There's nothing wrong with having an extra select() in
 > apm_get_events(), since the timeout can be zero.

That's fine.  I didn't know the level of abstraction meant to be
provided by the library.

Whew!  Enough for one night!

Craig