Date: Thu, 01 Feb 2007 12:44:37 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: rizzo@icir.org Cc: freebsd-arch@freebsd.org Subject: Re: configurable device (and other) tables in the kernel ? Message-ID: <20070201.124437.1474621167.imp@bsdimp.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20070201104506.B82313@xorpc.icir.org>
Luigi Rizzo <rizzo@icir.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070201.124437.1474621167.imp>