From owner-freebsd-current Sat Nov 23 2: 1: 9 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 38AEB37B401; Sat, 23 Nov 2002 02:01:08 -0800 (PST) Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBDA843E4A; Sat, 23 Nov 2002 02:01:07 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0024.cvx22-bradley.dialup.earthlink.net ([209.179.198.24] helo=mindspring.com) by swan.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18FX5u-0002vd-00; Sat, 23 Nov 2002 02:00:59 -0800 Message-ID: <3DDF4F16.85FAE3D9@mindspring.com> Date: Sat, 23 Nov 2002 01:49:10 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bruce Evans Cc: Mitsuru IWASAKI , kris@obsecurity.org, jhb@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: Lots of swapping from 'kldload acpi' References: <20021123201910.R48944-100000@gamplex.bde.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bruce Evans wrote: > The existence of SYSINIT is a bug, but shouldn't the order of SYSINITs be > such that they are run before MOD_LOAD events? > > SYSINITs have no way to communicate failure, so they are especially broken > when they are used to allocate resources. Users of the resources have no > way to tell whether the SYSINITs worked except to check for the existence > of the resources before using them, but if they can do that properly > then they can just call the resource allocation functions. The SYSINITs in the module load case can communicate failure, since it's the module load routine that handles them. The real answer here is that SYSINIT is intended for system initialization time operations. IF the system fails to initialize properly, there's really no way to communicate failure (for example, a failure prior to the console being up is very hard to report on a still-born console that has not be setup or initialized to do reporting). The function is void, because it makes no sense to trap an error condition you can't handle (Dennis Ritchie said this). It's true that the functions are void; however, in the context of the driver, they call functions which are locally defined, and therefore could update a static "errno"-type value, very easily, to report their status. Alternately, they could call a callback function, which was defined only in the module load case. I can provide sample code, if necessary. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message