Skip site navigation (1)Skip section navigation (2)
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>