From owner-freebsd-arch@FreeBSD.ORG Thu Feb 1 19:47:48 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 7B5F116A405; Thu, 1 Feb 2007 19:47:48 +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 1774F13C4BB; Thu, 1 Feb 2007 19:47:47 +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 l11Ji6m1063383; Thu, 1 Feb 2007 12:44:07 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 01 Feb 2007 12:44:37 -0700 (MST) Message-Id: <20070201.124437.1474621167.imp@bsdimp.com> To: rizzo@icir.org From: "M. Warner Losh" In-Reply-To: <20070201104506.B82313@xorpc.icir.org> References: <20070201091605.A82313@xorpc.icir.org> <20070201.110206.1102529050.imp@bsdimp.com> <20070201104506.B82313@xorpc.icir.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 12:44:07 -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 19:47:48 -0000 In message: <20070201104506.B82313@xorpc.icir.org> Luigi Rizzo writes: : 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. I'd forgotten about that. : 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') I'm not sure that I follow you here. : Surely it requires some form of rebuild of the kernel : but there doesn't seem to be any other way to possibly solve : the problem... The more serious problem is the need for someone who has a moderate clue and a lot of time to do grunt work to go through the tree and regularize the pci and usb busses, plus provide some infrasturcture to allow this information to be exported (currently the pnpinfo provided by busses gives one the device info, the other side of the coin is what's needed). Until we have that, talking about anything other than simple aliasing isn't going to get very far. Warner