From owner-freebsd-hackers Mon Mar 9 15:47:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA03028 for freebsd-hackers-outgoing; Mon, 9 Mar 1998 15:47:25 -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 PAA02847 for ; Mon, 9 Mar 1998 15:46:26 -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 SAA19471; Mon, 9 Mar 1998 18:45:37 -0500 (EST) (envelope-from walter@fortean.com) X-Authentication-Warning: aries.fortean.com: walter owned process doing -bs Date: Mon, 9 Mar 1998 18:45:37 -0500 (EST) From: "Bruce M. Walter" Reply-To: "Bruce M. Walter" To: Andrew Maltsev cc: freebsd-hackers@FreeBSD.ORG Subject: Re: APM power off (patch) In-Reply-To: <199803092330.CAA06308@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 > Ok. I understand. But should we distinguish devices and core system? > All the time I mean powering off core system after all devices were shut > down or powered down by their drivers - by at_shutdown queues or other > means. Yes. When I say device, I mean device driver. You can look at a UPS or an APM bios extension as a 'device'. The code for specific functions belongs in the driver, where it's interacted with by userland, the kernel etc, etc. > > 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 > > So, step 8) should be: > 8) reboot or power off, whatever requested. Well, I'm actually proposing it's taken out of the kernel (step 8) and put into the callout functions (step 5). The implementation of the SHUTDOWN_POWEROFF queue allows this by having a queue specifically for functions need to be called after EVERYTHING else related to shutdown is said and done. Steps 6,7 and 8 all are in the same category, but for various reasons stay in-kernel: Halt, because all it is is a tight loop. Panic (I presume) because it needs direct access to kernel information to perform a crash dump. Reboot is just a fallthrough which performs a hardware reset. - 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