From owner-freebsd-hackers Thu Jun 15 20: 9:37 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id BC66C37BA59; Thu, 15 Jun 2000 20:09:34 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p30-dn02kiryunisiki.gunma.ocn.ne.jp [211.0.245.95]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id MAA00958; Fri, 16 Jun 2000 12:09:30 +0900 (JST) Message-ID: <394992FE.AD77955E@newsguy.com> Date: Fri, 16 Jun 2000 11:37:50 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: mjacob@feral.com Cc: Mike Smith , hackers@FreeBSD.ORG Subject: Re: loading modules from within the kernel.... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Jacob wrote: > > > 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. That won't work on loader(8), since no code gets executed at that point. > > 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? AFAIK, they haven't changed since splash screen & loader(8) were first introduced, back in... october or november 1998. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@the.great.underground.bsdconpiracy.org "He is my minion, so he doesn't need a name." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message