Date: Thu, 1 Feb 2007 10:45:06 -0800 From: Luigi Rizzo <rizzo@icir.org> To: "M. Warner Losh" <imp@bsdimp.com> Cc: freebsd-arch@freebsd.org Subject: Re: configurable device (and other) tables in the kernel ? Message-ID: <20070201104506.B82313@xorpc.icir.org> In-Reply-To: <20070201.110206.1102529050.imp@bsdimp.com>; from imp@bsdimp.com on Thu, Feb 01, 2007 at 11:02:06AM -0700 References: <20070131115148.A60420@xorpc.icir.org> <200702011109.12821.jhb@freebsd.org> <20070201091605.A82313@xorpc.icir.org> <20070201.110206.1102529050.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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') 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... cheers luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070201104506.B82313>