Date: Tue, 1 Jan 2002 19:20:42 -0500 From: Mike Barcroft <mike@freebsd.org> To: Mike Smith <msmith@freebsd.org> Cc: Bruce Evans <bde@zeta.org.au>, Peter Pentchev <roam@ringlet.net>, arch@freebsd.org Subject: Re: kldload(2) family (was Re: loadable aio) Message-ID: <20020101192042.C64468@espresso.q9media.com> In-Reply-To: <200201012149.g01Lnhr01849@mass.dis.org>; from msmith@freebsd.org on Tue, Jan 01, 2002 at 01:49:42PM -0800 References: <20020101162447.A64468@espresso.q9media.com> <200201012149.g01Lnhr01849@mass.dis.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Smith <msmith@freebsd.org> writes: > > 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. > > This is absurd. It's (only) known at runtime. The kernel directory can > be (and is) moved aribitrarily. It has to be done inside the kernel to > allow demand-loading by the kernel. Can you give an example? Remember, my proposal is only for module dependencies that need to search for a file. > > 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. > > This demonstrates a basic misunderstanding of how the module system > works; you have not grasped the distinction between "module" and "file" > at all. > > The interface, from a userland perspective, is driven by three basic > requirements: > > 1) Load a named module. > 2) Load a named file. > 3) Unload a named module. > > 1) needs to search a database (in this case, built by kldxref) of known > modules to locate the file containing the module. It has a fallback > behaviour of assuming that the module 'foo' is found in the file 'foo.ko' > somewhere on the module searchpath. What is the syscall interface for this functionality? Presumably it's overloaded onto the kldload(2) interface? :) Here's what the kldload(2) manual says it does: : kldload - load KLD files into the kernel : : DESCRIPTION : The function kldload() loads a kld file into the kernel using the kernel : linker. Is this incorrect? > 2) takes a filename argument. As a convenience to the programmer, it > will append the '.ko' suffix, and search the system default path for the > file if an explicit pathname is not given. I don't consider this a convenience, nor do I consider open(2) searching the filesystem for a file I wish to open appropriate. > 3) is obvious, but misimplemented. > > There are a lot of problems with the current implementation, but you are > not addressing them in this thread. Don't butcher what is actually quite > a clean and functional design just because you don't understand it; try > fixing some of the really major conceptual problems, not dumbing it down > to the level of the implementation. Obviously I don't understand this. If you recall, earlier I called this interface black magic. I was hoping this thread would answer the question of why this interface is so evil, but you apparently saw this as an opportunity to insult my intelligence. 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?20020101192042.C64468>