From owner-freebsd-hackers Wed Jun 14 14:13:56 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 409EC37C37A; Wed, 14 Jun 2000 14:13:50 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id OAA07777; Wed, 14 Jun 2000 14:13:47 -0700 Date: Wed, 14 Jun 2000 14:13:39 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Mike Smith Cc: hackers@freebsd.org Subject: Re: loading modules from within the kernel.... In-Reply-To: <200006142114.OAA00463@mass.cdrom.com> 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 > > Since your driver initialisation is going to (often) happen before disk > I/O, I'd be inclined to put a dependancy in your module to another module > with a container object containing the firmware. Right. I would expect that the loader(8) would DTRT. Of course, this then raises an issue about how this might be supported statically as well! > Of course, this brings to light the fact that I don't think we support > "soft" dependancies, ie. load-this-if-you-can-but-don't-fail-if-you-can't. Oh, err, uh, that's gotta be fixed. Let the caller/invoker of a load action decide what the policy for failure is. > > The current school of thought for solving this would be to have your > firmware load as a plain container in a fashion similar to the way we > load the MFS root image, and then use preload_search_by_type() to locate > it. Does this approach use functions/APIs that are likely to not change for a while? -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message