From owner-freebsd-arch@FreeBSD.ORG Mon Nov 21 19:45:25 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4498716A41F for ; Mon, 21 Nov 2005 19:45:25 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF88C43D5D for ; Mon, 21 Nov 2005 19:45:21 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id jALJiEQf045255; Mon, 21 Nov 2005 12:44:14 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 21 Nov 2005 12:44:13 -0700 (MST) Message-Id: <20051121.124413.59698313.imp@bsdimp.com> To: scottl@samsco.org From: Warner Losh In-Reply-To: <43821E3E.3000106@samsco.org> References: <23495346.1132600653230.JavaMail.root@vms068.mailsrvcs.net> <43821E3E.3000106@samsco.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Mon, 21 Nov 2005 12:44:14 -0700 (MST) Cc: arch@freebsd.org, babkin@users.sourceforge.net, damien.bergamini@free.fr, nate@root.org Subject: Re: cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi if_iwi.c if_iwi X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2005 19:45:25 -0000 > The loader can, that's how the mfsroot.gz file gets loaded > during install. /boot/loader can do this certainly. And you can lookup a file based on its name from the in-kernel loader. However, there doesn't appear to be a linker class that can load arbitrary files. The in-kernel linker can only lookup things loaded at boot time. I think that creating a link_file might be a good alternative to having drivers do vfs operations directly. The kernel would load it safely and hand a reference to the file to the driver. The driver can then frob it into the hardware and unload the module. The problem would be that you'd want to make sure that the elf loader got a chance to reject the module before the arbitrary file loader, or you'd need to make the arbitrary file loader not load elf. We may be able to 'widen' the interface to drivers a bit by exposing linker_load_file to the outside world. We could then have the arbitrary file loader 'fail' the LINKER_LOOKUP_SET method fail so that linker_load_module would still give the current behavior. That might be better than a priority scheme, and would answer my main objection to kld modules... Warner