From owner-freebsd-arch Tue Jan 1 13:27:34 2002 Delivered-To: freebsd-arch@freebsd.org Received: from espresso.q9media.com (espresso.q9media.com [216.254.138.122]) by hub.freebsd.org (Postfix) with ESMTP id A530237B639; Tue, 1 Jan 2002 13:27:17 -0800 (PST) Received: (from mike@localhost) by espresso.q9media.com (8.11.6/8.11.6) id g01LOlf64937; Tue, 1 Jan 2002 16:24:47 -0500 (EST) (envelope-from mike) Date: Tue, 1 Jan 2002 16:24:47 -0500 From: Mike Barcroft To: Bruce Evans Cc: Peter Pentchev , Mike Smith , arch@FreeBSD.ORG Subject: Re: kldload(2) family (was Re: loadable aio) Message-ID: <20020101162447.A64468@espresso.q9media.com> References: <20011231043633.E45114@espresso.q9media.com> <20020101025947.L6989-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020101025947.L6989-100000@gamplex.bde.org>; from bde@zeta.org.au on Tue, Jan 01, 2002 at 03:22:40AM +1100 Organization: The FreeBSD Project 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 Bruce Evans 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