From owner-freebsd-hackers Mon Mar 9 15:02:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA22498 for freebsd-hackers-outgoing; Mon, 9 Mar 1998 15:02:10 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from aries.fortean.com (aries.fortean.com [209.42.194.114]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA22304 for ; Mon, 9 Mar 1998 15:01:44 -0800 (PST) (envelope-from walter@fortean.com) Received: from localhost (walter@localhost) by aries.fortean.com (8.8.8/8.8.8) with SMTP id RAA18130; Mon, 9 Mar 1998 17:58:54 -0500 (EST) (envelope-from walter@fortean.com) X-Authentication-Warning: aries.fortean.com: walter owned process doing -bs Date: Mon, 9 Mar 1998 17:58:54 -0500 (EST) From: "Bruce M. Walter" To: Andrew Maltsev cc: freebsd-hackers@FreeBSD.ORG Subject: Re: APM power off (patch) In-Reply-To: <199803092225.BAA05980@amsoft.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > The idea is to have a kernel callout hook using the at_shutdown interface. > > Please forgive me my stupidness - I still cannot understand what can be > broken by calling something_power_off as a very last step of system > shutdown procedure? Yes, all that at_shutdown, at_very_shutdown and so > on may exist, but what difference does it make? Not stupidness! I just went through these same things and would hate to see someone else do the same thing :) Here's a fairly long winded overview of my particular case. It gives an example of the use/reasoning. The idea is that via at_shutdown, the kernel doesn't actually need to know anything specifi about the shutdown code. That code exists within the apm device driver and could even be an LKM outside the kernel. In my case, my ups driver loads, and waits for a go-ahead signal and configuration to come in via ioctl's from a monitoring daemon. Once the daemon gives the driver the go-ahead, the driver installs a poweroff function on the SHUTDOWN_POWEROFF queue via at_shutdown and begins to monitor the serial line to the UPS. If a powerfail occurs, the daemon is notified. When it decides to poweroff the system, executes the command 'reboot -p'. This starts a kernel shutdown with the RB_POWEROFF flag set. The system then goes through a regular reboot/shutdown sequence: 1) Execute all registered SHUTDOWN_PRE_SYNC functions 2) Kill all processes 3) Sync the filesystem 4) Execute all registered SHUTDOWN_POST_SYNC functions 5) (with patches) Execute all registered SHUTDOWN_POWEROFF functions 6) Halt if requested 7) Check for a panic 8) Reboot Steps 1, 4 and 5 call functions which can exist outside the kernel in drivers and LKM's. These functions have access to the RB_* flags passed to reboot and can do whatever they need to poweroff the system. My UPS driver sends the power inverter kill signal on the serial line when it's SHUTDOWN_POWEROFF function is called with the RB_POWEROFF flag. The kernel doesn't need any special poweroff functions, only the drivers. My argument would be for an APM device driver to register a poweroff function in this manner and check the RB_POWEROFF flag passed to reboot to see if it needs to poweroff when the function called... So it's not so much what you do, but how you do it :) - Bruce ======================================================================== || Bruce M. Walter || 107 Timber Hollow Court #335 || || Senior Network Consultant || Chapel Hill, NC 27514 || || Fortean Technologies, Inc. || Tel: 919-967-4766 || || Information Technology Consultants || Fax: 919-967-4395 || ======================================================================== || BSD Unix -- It's not just a job, it's a way of life! || ======================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message