From owner-freebsd-current Wed May 10 1:10:37 2000 Delivered-To: freebsd-current@freebsd.org Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by hub.freebsd.org (Postfix) with ESMTP id 1C6E837B69C; Wed, 10 May 2000 01:10:29 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by anchor-post-32.mail.demon.net with esmtp (Exim 2.12 #1) id 12pRZU-000DvD-0W; Wed, 10 May 2000 09:10:20 +0100 Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id JAA16819; Wed, 10 May 2000 09:13:39 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Wed, 10 May 2000 09:15:00 +0100 (BST) From: Doug Rabson To: Mike Smith Cc: shimon@simon-shapiro.org, freebsd-current@freebsd.org Subject: Re: EVENTHANDLER_DECLARE In-Reply-To: <200005100215.TAA21503@mass.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 9 May 2000, Mike Smith wrote: > > > > On 10-May-00 Mike Smith wrote: > > >> Sorry to bother y'll, but; > > >> > > >> Has anyone ever used that? I see no trace of any kernel > > >> code calling it, and the at_shutdown code appears to be > > >> gone. > > > > > > It's still used in the shutdown code; it was meant to be available for > > > general use elsewhere, but I haven't seen anyone playing with it, so > > > maybe the design tradeoffs were bad choices. > > > > I dunno. It seems to do anything I need; Call me with an argument. > > I do not even need the priority. > > It won't notify you that your code is about to be removed from the kernel. > > > >> BTW, for all it is worth, any caching controller not using > > >> this is guaranteed to lose data. > > > > > > Wrong layer. You should be using the bus shutdown method; look at eg. > > > the Mylex driver to see how this is done. You should probably call your > > > flush routine from the suspend method as well. > > > > This is dangerous for the OSM. When the i2o OSM shuts an IOP > > down, it is history. It will stop doing any work at all; network, > > disk, console, mouse, whatever. I reserve that for really, really > > shutdown/reset. > > I'm not sure I understand what you mean by "dangerous". When your > shutdown method is called, you're being told that you're about to stop > being able to control your hardware, either because your code is about to > be removed from the kernel (module unload) or because the system is being > shut down. Actually, DEVICE_DETACH is called when the driver is unloaded and it can return an error which should abort the unload. If DEVICE_SHUTDOWN is called, then you have no choice - the kernel is stopping soon and this is your last change to tidy up. > > Before you return success from your shutdown method, you must have > brought your hardware to a quiescent state, ready for immediate loss of > power. It must not generate any more interrupts or access any more data > once you have returned. > > You can veto your shutdown (by returning nonzero), which will fail a > module unload, but _will_not_ fail a kernel shutdown. See above - you can veto detach but not shutdown. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message