Date: Tue, 1 Jan 2002 03:22:40 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Mike Barcroft <mike@FreeBSD.ORG> Cc: Peter Pentchev <roam@ringlet.net>, Mike Smith <msmith@FreeBSD.ORG>, <arch@FreeBSD.ORG> Subject: Re: kldload(2) family (was Re: loadable aio) Message-ID: <20020101025947.L6989-100000@gamplex.bde.org> In-Reply-To: <20011231043633.E45114@espresso.q9media.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 31 Dec 2001, Mike Barcroft wrote:
> [Moved to -arch, BCC'd to -hackers.]
>
> Peter Pentchev <roam@ringlet.net> writes:
> > Okay, so it's not documented in the manual, but one look at the source
> > should suffice :)
>
> :(
>
> > As Mike said, there is a search path. However, the current directory
> > is tried first. If a file by that name is not found in the current
> > directory, the search path is, well, searched ;) The search path
> > is available in the kern.module_path sysctl or in the output of
> > 'kldconfig -r'.
>
> Oh no, it's worse than I feared.
I recently noticed some more brokenness related to this. The following
commit:
RCS file: /home/ncvs/src/sys/conf/kmod.mk,v
Working file: kmod.mk
head: 1.109
...
----------------------------
revision 1.106
date: 2001/08/08 13:51:10; author: green; state: Exp; lines: +2 -2
In the KLD "load" make target, don't load using the "absolute" path of
"./foo.ko". Use "/full/path/foo.ko" instead so that when the path is
reported as being an absolute path to the "shared library", at least
it's not really a relative path.
Obtained from: LOMAC/FreeBSD project
----------------------------
perfectly breaks "make load" for the usual case where there is a separate
obj directory, by using a wrong absolute path (one involving ${.CURDIR}
instead of ${.OBJDIR}.
There was some discussion of the brokenness in followup to this commit.
Relative paths like "foo.ko" should work in the Unix way IMO (the "./"
in "./foo.ko" was apparently a failed attempt to prevent searching
like it would in the shell). The syscall should not do any searching,
especially not in a misdesigned undocumented insecure search path with
DOS-style separators.
> > This is similar to what shells have been doing for decades, with
> > the added feature of an implicit '.' at the start of the search path.
>
> Yes, the usual approach shells take is much better designed.
>
> Here's how I would design this interface:
> o _kldload(2) accepts a file path (similar to open(2))
> o kldunload(2) accepts a filename (no path)
> o kldload(3) accepts a module name (procfs), file name (procfs.ko), or
> file path (/boot/kernel/procfs.ko).
> o Search paths for kldload(3) are controlled by the environment
> variable `KLDPATH' (similar to MANPATH and PATH).
> o When kldload(3) locates a module file, it calls _kldload(2).
> o kldload(8) uses kldload(3)
> o kldunload(8) uses kldunload(2)
>
> The main advantage of this design is that it allows a Unix programmer
> to utilize it. :)
I would intentionally leave out kldload(3). There is a problem converting
relative names to absolute ones for auto-loading things like filesystems
in the kernel, but there is no problem in userland -- the modules are
wherever you installed or built them.
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020101025947.L6989-100000>