ups/power management techniques

VaX#n8 (vax@linkdead.paranoia.com)
Sat, 15 Aug 1998 04:26:36 -0500


Apologies for sending to such a broad audience.

I have been working quite hard on a cable, adapting electronics,
and UPS monitoring software for NetBSD.

I sent an email to the vendor about building a cable, and was
told it wasn't possible. Naturally, I could not resist this challenge.
I examined the Linux UPS HOWTO, various web pages, and built my own
(learning quite a bit about RS-232 in the process).
I was a little surprised to find that most of the serial communication
information on the Internet began and ended with pin assignments.
I couldn't even find a suitable newsgroup to ask questions in.

After investigating several of the Linux packages, I decided it would
still be worthwhile (instructive) to write my own. I've done so.
However, my UPS only supports immediate shutdown (by raising a serial
line for 50 milliseconds). This led to some rather interesting
race conditions when trying to implement it in a stand-alone daemon.

So, I figured I'd query the collective open-source knowledge base.

Searching various mailing list archives has tended to generate more
heat than light - there's a number of terms and synonyms people could
use in describing the issue, and there are far more people asking
where to find a particular software package than in discussing
the real issues.

So the questions I want to ask are:
1) What kind of kernel support would handle this in the cleanest way?
2) Where should the shutdown signal be asserted; in the userland
monitoring program, the reboot command, the kernel reboot(2),
or the instruction before HALT? ;)
3) Should there be any special handling after a powerfail shutdown?
Specifically, should the OS idle in single-user mode until some
condition is met, to avoid yo-yo-ing?
4) Anything else?

I will summarize in a web page, so you need only email me
and check my home page later (see the mail headers).
Cc any mailing list at your own peril.
While I wouldn't mind a cross-list technical discussion about
the various approaches, they haven't worked in the past.

Apologies for my semi-literacy; it has been a long night.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html