From owner-freebsd-arch@FreeBSD.ORG Tue Nov 22 00:53:52 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 53EC816A41F for ; Tue, 22 Nov 2005 00:53:52 +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 D9C5143D45 for ; Tue, 22 Nov 2005 00:53:51 +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 jAM0qxkd048361; Mon, 21 Nov 2005 17:52:59 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 21 Nov 2005 17:53:15 -0700 (MST) Message-Id: <20051121.175315.56348077.imp@bsdimp.com> To: babkin@users.sourceforge.net, babkin@verizon.net From: "M. Warner Losh" In-Reply-To: <43825BFD.70B5E055@verizon.net> References: <43821E3E.3000106@samsco.org> <20051121.124413.59698313.imp@bsdimp.com> <43825BFD.70B5E055@verizon.net> 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 17:52:59 -0700 (MST) Cc: arch@freebsd.org, damien.bergamini@free.fr, nate@root.org Subject: Re: cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi if_iwi.cif_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: Tue, 22 Nov 2005 00:53:52 -0000 In message: <43825BFD.70B5E055@verizon.net> Sergey Babkin writes: : Warner Losh wrote: : > : > > 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. : : I didn't get the e-mails in between yet, so maybe this has been : already mentioned, but I'd also have the offset in the file and : maximal length to read as arguments. This would allow the drivers : to read large files by loading a reasonably small portion at a time. That might be an interesting optimization. I'm not sure that it would necessarily be all that useful. The firmware images currently are in the 32-256k range each. The ispfw driver is only 450k total (and has several firmware images, iirc). While it is desirable to be able to use this extra memory all the time, this isn't so much memory that we couldn't allocate and free it as needed. The only gotcha would be to make sure that our linker doesn't suffer address space leakage because these files would be mapped and unmapped a lot more often than a normal module. Warner