From owner-freebsd-arch@FreeBSD.ORG Thu Feb 1 23:01:05 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.ORG Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4785716A405; Thu, 1 Feb 2007 23:01:05 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id DF86713C491; Thu, 1 Feb 2007 23:01:04 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id l11MwbQ0065961; Thu, 1 Feb 2007 15:58:37 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 01 Feb 2007 15:59:08 -0700 (MST) Message-Id: <20070201.155908.-957832847.imp@bsdimp.com> To: jhb@FreeBSD.ORG From: "M. Warner Losh" In-Reply-To: <200702011614.48712.jhb@freebsd.org> References: <20070201.110206.1102529050.imp@bsdimp.com> <20070201104506.B82313@xorpc.icir.org> <200702011614.48712.jhb@freebsd.org> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 01 Feb 2007 15:58:37 -0700 (MST) Cc: freebsd-arch@FreeBSD.ORG Subject: Re: configurable device (and other) tables in the kernel ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2007 23:01:05 -0000 In message: <200702011614.48712.jhb@freebsd.org> John Baldwin writes: : On Thursday 01 February 2007 13:45, Luigi Rizzo wrote: : > On Thu, Feb 01, 2007 at 11:02:06AM -0700, M. Warner Losh wrote: : > ... : > > : plain text files! : > > : : > > : too obvious to think of it :) : > > : : > > : but, where can i find an example of a piece of kernel code that can : > > : read from a file "safely" (i.e. say in the modevent handler or maybe : > > : at device probe time) ? : > > : Something like : > > : : > > : char *load_file_into_kernel_memody(filename, max_size, &error); : > > : : > > : I have looked at the kernel side of execve and kldload, they are not : > > : exactly straightforward (at least there are seveal indirections). : > > : Maybe there are other simpler ones ? : > > : > > Look at the firmware routines. However, they won't work until / is : > > mounted, which is after all the device probing happens. : > : > unfortunately firmare images are embedded in .ko files, so the loading : > is done elsewhere - but ok, i can spend some time figuring out : > what LINKER_LOAD_FILE() does and whether it is just plain loading : > of the file in memory or more than that, whether it can be made to : > work even with an unstructured file, and so on. : > : > Re. the availability of / - one of the requirements i had written : > was the ability to preload the table at compile time - that's the : > easy part, in the end it is just some macro/scripting magic to embed : > the initial table in the object. : > Short of putting into the table some hooks to give control : > to the console and ask the user to manually type in : > the 'alias ID' you were referring to (in the good old times : > maybe someone would have even conceived a 'please type : > the full driver image in hex') : : Why not do what firmware(9) does? You can take a table and turn it into a : module and then either load that via the loader or kldload it at runtime (or : use linker_reference_module(9) at runtime). Granted, I still think the : concept is not really a good idea, but I think firmware(9) is actually a good : model for this sort of thing. Assuming that you have the infrastructure to produce the tables, then yes. See my other posts for the issues with that assumption Warner