From owner-freebsd-arch Tue Jan 1 13:41: 9 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 0E08D37B425; Tue, 1 Jan 2002 13:41:05 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id g01Lnhr01849; Tue, 1 Jan 2002 13:49:43 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200201012149.g01Lnhr01849@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Mike Barcroft Cc: Bruce Evans , Peter Pentchev , Mike Smith , arch@FreeBSD.ORG Subject: Re: kldload(2) family (was Re: loadable aio) In-reply-to: Your message of "Tue, 01 Jan 2002 16:24:47 EST." <20020101162447.A64468@espresso.q9media.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 01 Jan 2002 13:49:42 -0800 From: Mike Smith 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 > > 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. > 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. 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. 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. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message