Does this make sense, or am I totally off-base?
On Sat, 18 May 1996, Richard Guenther wrote:
> On Sat, 18 May 1996, Bjorn Ekwall wrote:
>
> > Hi all!
> >
> > Here is support for a "generic" interpreter, via kerneld!
> > (Would you expect anything but a kerneld solution from me? :-) )
> >
>
> This is the right and only way to do this!
> (Linus: take out binfmt_java before 2.0 -- please!!!)
In line with Linus' comment (and mine, ooooh, I was actually sort of on the
side of the Great One this time 8) 8) 8) I think this approach has the
problem of transferring `kernel bloat' to `kernel-extension-bloat-hidden-
in-user-space<tm>' or, as we call it, kebhius.... (well, I thought it was
time to invent a term....lowercase it and pronounce it something like
`kevius').... :)
Still though, some of us like the idea of flexible executable formats that
can be added to Linux at a moment's notice to Confound The Enemies of the
One True Operating System<tm>. :) I'd suggest that the kernel module could
get a bit larger and use a file in /proc/sys into which the administrator
can write a line containing the following values for each extension binary
format:
(1) a magic string to check for,
(2) a path to exec in order to run the binary,
(3) optional flags which indicate things like whether suid and sgid bits
should be honored for this format
This has the advantages that:
(1) it keeps the criteria for extension binary execution in the kernel,
where executable formats are normally selected now,
(2) it keeps more hard-coded paths out of the kernel, which a lot of us
consider a positive good,
(3) it results in fewer interactions between kernel and user space; there
is no daemon, and invalid executable formats don't especially need
a transfer to user space to produce an error message unless the admin
has a clearly-documented (and hence easier to debug) masochistic streak,
and
(4) it preserves the flexibility of configurable extension executable
formats without adding Yet Another Daemon<tm>....
Comments? Flames? Free popcorn? :)
lilo