From owner-freebsd-hackers Thu Oct 5 17:04:49 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA28803 for hackers-outgoing; Thu, 5 Oct 1995 17:04:49 -0700 Received: from psychotic.communica.com.au (root@gw.communica.com.au [203.8.94.161]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA28790 for ; Thu, 5 Oct 1995 17:04:08 -0700 Received: from communica.com.au (newton@frenzy [192.82.222.1]) by psychotic.communica.com.au (8.6.12/8.6.9) with SMTP id JAA11387; Fri, 6 Oct 1995 09:32:34 +0930 Received: by communica.com.au (4.1/SMI-4.1) id AA01874; Fri, 6 Oct 95 09:29:21 CST From: newton@communica.com.au (Mark Newton) Message-Id: <9510052359.AA01874@communica.com.au> Subject: Re: Fiskars UPS support... To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Fri, 6 Oct 1995 09:29:20 +0930 (CST) Cc: hackers@freefall.freebsd.org In-Reply-To: <651.812900154@critter.tfs.com> from "Poul-Henning Kamp" at Oct 5, 95 02:35:54 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1746 Sender: owner-hackers@FreeBSD.org Precedence: bulk Poul-Henning Kamp wrote: > > I know this isn't your priority, but it would be nice if this could be > > devoloped in some sort of modular fashion, separating the control logic > > from the UPS-specific interface code. > > I agree, the right thing is probably to define a interface somehow, but > couldn't this be as simple as executing a command with explanatory > args: I mentioned this to miff in private email, but I may as well float it here with the rest of the group: How about another keyword to be inserted in the ty_status field in /etc/ttys, such as: tty08 "/usr/libexec/getty std.9600" vt100 on secure tty09 "/usr/sbin/upsmon" none ups The "ups" keyword would mean, "respawn this process upon entry to multiuser mode; continue to respawn it until the CPU halts, regardless of changes between multiuser and singleuser state." ... then all the UPS-specific interface code would be handled by the UPS-specific "/usr/sbin/upsmon" process. The advantage of this approach is that upsmon would then continue to run in single-user mode, meaning that if you ever shut the system down on the expectation that the batteries are about to run out, and the power comes back on as soon as you've hit single-user mode, upsmon will still be able to see that event and wake the system up again (which eliminates the possibility of getting stuck in single-user mode if you do a shutdown 3 seconds before the mains power comes back online). Even really stupid UPSs would work well with this feature :-) - mark --- Mark Newton Email: newton@communica.com.au Systems Engineer Phone: +61-8-373-2523 Communica Systems WWW: http://www.communica.com.au