Re: configurable device (and other) tables in the kernel ?



In message: <200702011614.48712.jhb@xxxxxxxxxxx>
John Baldwin <jhb@xxxxxxxxxxx> 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
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"