Well, I know that the way I sometimes express myself might need an
explicit ":-)" (or two...) Anyway, it still has to be _executable_...
What I showed was that kerneld is perfectly able to give the kernel
support for quite a lot of things, including the knowledge of how
to handle different types of executables.
I use kerneld as a way to try out things in user space before I
try to implement something in kernel space. Sometimes one finds
that part of the solution should _remain_ in user space, and for
executables I feel that the original recognition _should_ be made
in user space.
On the other hand, I also think that it is kerneld's job to "learn"
the kernel how to handle this the _next_ time, so that the kernel
won't have to keep a full (mini-)"file" implementation within the kernel,
that has to be maintained in some way...
As I said; this was a "proof of concept", and in the "real" solution
kerneld will be able to store the recognition pattern within the kernel
instead. But the pattern won't be (shouldn't be) stored in the kernel
until the need arises, unless it is a "standard" format, such as ELF,
aout or "#!"-scripts.
In some of the next snapshots of the module utilities, which might even
be an official relase, I intend to include a dynamic "blacklist" support
for most of the kerneld requests, so that kerneld can inform the kernel
immediately that some requests are not supported.
It is much easier for kerneld to recognize when the sysadmin has updated
the configuration files than what it is for the kernel.
I earlier sent a patch to Linus that put a subset of this "blacklist"
inside the kernel, but I lean more and more towards the opinion that
the "blacklist" should reside in kerneld, and not in the kernel.
The overhead of a kerneld call is quite small, and with the possibilities
of a rapid answer (i.e. "unsupported request") the possibilities
for the sysadmin to configure the system "on the fly" is much better.
Anyhow, you still have to maintain _some_ kind of configuration file,
even if you don't let kerneld do the job for you...
B.t.w.: I just found an executable "data" file on one of my seldom used
partitions. It was called "sol.exe", and on the spur of the moment,
I added the following line to the "def_fmt[]" array in "binfmt.c" from
the "proof of concept":
{ "MZ", 2, "#!/usr/local/bin/wine"},
I then just typed "sol.exe", and it worked... Weird experience...
(I.e.: wine is really starting to look _good_!).
Greetings,
Bjorn