From owner-freebsd-arch@FreeBSD.ORG Sat Feb 3 11:55:03 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 F157F16A400 for ; Sat, 3 Feb 2007 11:55:03 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id B976013C442 for ; Sat, 3 Feb 2007 11:55:03 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 61FF846C4A; Sat, 3 Feb 2007 06:55:03 -0500 (EST) Date: Sat, 3 Feb 2007 11:55:03 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Luigi Rizzo In-Reply-To: <20070201104506.B82313@xorpc.icir.org> Message-ID: <20070203115235.W91177@fledge.watson.org> References: <20070131115148.A60420@xorpc.icir.org> <200702011109.12821.jhb@freebsd.org> <20070201091605.A82313@xorpc.icir.org> <20070201.110206.1102529050.imp@bsdimp.com> <20070201104506.B82313@xorpc.icir.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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: Sat, 03 Feb 2007 11:55:04 -0000 On Thu, 1 Feb 2007, Luigi Rizzo wrote: >> 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') > > 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 preferred way to make configuration frobs available during early boot is via the hints mechanism, which supports both loading data via the loader, compiling it into the kernel, and updating it using kenv(8). I'd really like us avoid adding yet more file access dependencies in the kernel. These tend to be fragile, can only run in certain contexts, run into issues with changing roots, etc. Could we add /boot/deviceids.hints to match /boot/device.hints? Robert N M Watson Computer Laboratory University of Cambridge