Date: Tue, 1 Jan 2002 16:24:47 -0500 From: Mike Barcroft <mike@FreeBSD.ORG> To: Bruce Evans <bde@zeta.org.au> 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: <20020101162447.A64468@espresso.q9media.com> In-Reply-To: <20020101025947.L6989-100000@gamplex.bde.org>; from bde@zeta.org.au on Tue, Jan 01, 2002 at 03:22:40AM %2B1100 References: <20011231043633.E45114@espresso.q9media.com> <20020101025947.L6989-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans <bde@zeta.org.au> writes:
> 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.
Right. I think the searching problem inside the kernel could be
conquered by requiring that the destination of the kernel modules be
known at compile-time.
> > 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.
I was concerned that some people might want compatibility with the
current behavior, but that doesn't seem to be the case (from this and
other private e-mails). The interface becomes much simpler without
kldload(3).
o kldload(2) accepts a file path (similar to open(2))
o kldunload(2) accepts a filename (no path, eg: "procfs.ko")
o kldload(8) uses kldload(2)
o kldunload(8) uses kldunload(2) (this could do extra string
manipulation for compatibility with `kldunload procfs').
o Module dependencies are handled by explicitly hardcoding the path to
the module directory at compile-time.
The only problem I see with hardcoding the path is when loading
modules in a chroot() environment. For example:
%%%
chroot("/boot");
chdir("/");
kldload("kernel/procfs.ko");
%%%
Obviously, the pseudofs.ko dependency would fail because
`/boot/kernel/pseudofs.ko' doesn't exist, but this is a common problem
in chroot() and jail() environments and is usually overcome by
recreating the directory hierarchy.
Best regards,
Mike Barcroft
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?20020101162447.A64468>