From owner-freebsd-hackers Fri Feb 6 13:13:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA00889 for hackers-outgoing; Fri, 6 Feb 1998 13:13:57 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA00877 for ; Fri, 6 Feb 1998 13:13:48 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id HAA00923; Sat, 7 Feb 1998 07:33:35 -0800 (PST) Message-Id: <199802071533.HAA00923@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Bruce M. Walter" cc: John Fieber , Mike Smith , hackers@FreeBSD.ORG Subject: Re: Powering off the system/UPS In-reply-to: Your message of "Fri, 06 Feb 1998 11:53:21 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 07 Feb 1998 07:33:35 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe hackers" > > [I say "illusion" because if the time between a low battery > > warning and a dead battery is less than your halt(8) time, you > > are SOL either way. With a sufficiently smart and powerful UPS, > > you should be able to avoid such situations though.] > > My empirical testing shows that at least the TrippLite and APC dumb UPS > models pull the low battery trigger about 2-3 minutes before failure. > This seems sufficient even for my big nasty machines, but user milage may > vary. With a toy UPS, the *only* thing that makes any sense is to gather your skirts as soon as it's obvious you're not looking at a 5-second dropout. (Read up on the shelf life of lead-acid gel batteries if this confuses you.) Because this is local policy, it's something that belongs in a userspace tool, which the proposed architecture supports. > I'm working on reorganizing the kernel code to allow for this right now... > Here's what I'm attempting as per Mike's suggestions: > > 1) There will be another queue, tenatively called 'SHUTDOWN_PRE_HALT' > which will run after SHUTDOWN_POST_SYNC and before an actual reboot/halt. SHUTDOWN_POWEROFF > int > pri_at_shutdown(bootlist_fn func, void *arg, int when, int priority); Maybe at_shutdown_pri(), but I think that's not a bad idea. Actually, I would go further and make at_shutdown() a macro, to emphasise that it's a shortcut version. Make the priority gap much wider though, eg. 0-10000 or more. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\