From owner-freebsd-arch Mon Dec 31 8:23: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 9309B37B41F; Mon, 31 Dec 2001 08:22:51 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id DAA05958; Tue, 1 Jan 2002 03:22:49 +1100 Date: Tue, 1 Jan 2002 03:22:40 +1100 (EST) From: Bruce Evans X-X-Sender: To: Mike Barcroft Cc: Peter Pentchev , Mike Smith , Subject: Re: kldload(2) family (was Re: loadable aio) In-Reply-To: <20011231043633.E45114@espresso.q9media.com> Message-ID: <20020101025947.L6989-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 31 Dec 2001, Mike Barcroft wrote: > [Moved to -arch, BCC'd to -hackers.] > > Peter Pentchev 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