Date: Mon, 21 Nov 2005 12:44:13 -0700 (MST) From: Warner Losh <imp@bsdimp.com> To: scottl@samsco.org 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 Message-ID: <20051121.124413.59698313.imp@bsdimp.com> In-Reply-To: <43821E3E.3000106@samsco.org> References: <23495346.1132600653230.JavaMail.root@vms068.mailsrvcs.net> <43821E3E.3000106@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051121.124413.59698313.imp>