Re: kerneld & binfmt_aout

H. Peter Anvin (
13 Dec 1997 13:07:34 GMT

Followup to: <>
By author: Martin von Loewis <>
In newsgroup:
> IMHO, this shows that binfmt autoloading is not meant to work.
> There are three options:
> a) deprecate the feature, leave the code as-is, document the limitations.
> b) try to make some new clever approach. For example, passing the
> file name of the executable seems to be a much more reliable approach
> than passing the first n bytes. kerneld could then do what file(1) does,
> perhaps passing a different magic file that spits out the name of
> the module.
> c) continue the current road: change the aliasing every m kernel versions,
> so ongoing confusion is guaranteed :-(
> Since we have binfmt_misc now, option a) seems to work best. There are
> only so many 'true' binary formats per architecture, everything else
> falls in the interpreter category and is thus handled by binfmt_misc.

d) Generalize binfmt_misc to be able to request a kernel module. This
may mean that binfmt_misc might have to be special-cased in a way
it isn't now, but the idea is the same: rather than relying on
kerneld to be able to parse the stuff the kernel sends up, tell the
kernel what we can handle, how to look for it, and what to do if we
trip on it.


    PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD  1E DF FE 69 EE 35 BD 74
    See for web page and full PGP public key
        I am Bahá'í -- ask me about it or see
   "To love another person is to see the face of God." -- Les Misérables