Date: Mon, 31 Dec 2001 13:56:53 +0200 From: Peter Pentchev <roam@ringlet.net> To: Mike Barcroft <mike@freebsd.org> Cc: Mike Smith <msmith@freebsd.org>, arch@freebsd.org Subject: Re: kldload(2) family (was Re: loadable aio) Message-ID: <20011231135653.A40563@straylight.oblivion.bg> In-Reply-To: <20011231043633.E45114@espresso.q9media.com>; from mike@freebsd.org on Mon, Dec 31, 2001 at 04:36:33AM -0500 References: <20011230215630.B45114@espresso.q9media.com> <200112310508.fBV58MI03596@mass.dis.org> <20011231034807.D45114@espresso.q9media.com> <20011231105940.B3512@straylight.oblivion.bg> <20011231043633.E45114@espresso.q9media.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Dec 31, 2001 at 04:36:33AM -0500, 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 hope you've seen my follow-up, in which I corrected my gross mistake. There is no current directory; the situation is actually absolutely equivalent to the approach shells take. If you specify a full path name, _kldload(2) loads that file; if you specify just a file name, _kldload(2) searches the path. > > 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. It is used here, too; sorry for the confusion that I caused. > 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. :) The main problem with this design, as I see it, is that it is highly centered around userland programs. There are many cases when kernel code needs to load a module - as a very simple example, consider module dependencies or the case of the initial kernel booting and preloaded modules :) (remember, the kernel itself is also a module) Kernel code has no concept of 'environment' (or rather, should not need to have any); thus, the search path needs to reside in the kernel. It does now, in the form of a sysctl, which also allows userland code to examine and/or change it, either by sysctl(8), or by kldconfig(8). The current design (as far as I understand it) goes something like: o linker_search_path(9) accepts a module name (procfs), file name (procfs.ko) or file path (/boot/kernel/procfs.ko). o Search paths for linker_search_path(9) are controlled by the kernel variable linker_path, exported as the kern.modules_path sysctl. o _kldload(2) uses linker_search_path(9) o kldunload(2) accepts a file ID, obtained from a call to kldfind(2) o kldload(3) uses _kldload(2) o kldload(8) uses kldload(3) o kldunload(8) uses kldfind(2) and kldunload(2) Okay, so the kldfind/kldunload part is somewhat weird, but once you accept that the kernel, too, needs to load modules (without any kind of information as to a running process and the environment thereof), the _kldload(2) and linker_search_path(9) path seems to become as clear as it could be :) G'luck, Peter -- This sentence no verb. 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?20011231135653.A40563>