Date: Sat, 23 Nov 2002 01:49:10 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Bruce Evans <bde@zeta.org.au> Cc: Mitsuru IWASAKI <iwasaki@jp.FreeBSD.org>, kris@obsecurity.org, jhb@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: Lots of swapping from 'kldload acpi' Message-ID: <3DDF4F16.85FAE3D9@mindspring.com> References: <20021123201910.R48944-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DDF4F16.85FAE3D9>