Date: Mon, 21 Nov 2005 17:53:15 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: babkin@users.sourceforge.net, babkin@verizon.net 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 Message-ID: <20051121.175315.56348077.imp@bsdimp.com> In-Reply-To: <43825BFD.70B5E055@verizon.net> References: <43821E3E.3000106@samsco.org> <20051121.124413.59698313.imp@bsdimp.com> <43825BFD.70B5E055@verizon.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <43825BFD.70B5E055@verizon.net>
Sergey Babkin <babkin@verizon.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051121.175315.56348077.imp>