Hi all,
I've been working on javawrapper, a utility which uses the binfmt_misc
kernel module to let you execute Java classes like any other program -
'./MyProgram.class' instead of 'java MyProgram.class'. For those of you
unfamiliar with binfmt_misc, the documentation is in
Documentation/binfmt_misc.txt in the kernel sources (since 2.1.43). It
occurred to me while I was writing the init.d script (with the advice of
my sponsor (cc'ed), IANYAD) that most of what I was doing was reusable.
I'm not aware at the moment of any packages that use binfmt_misc; please
somebody let me know if I'm wrong. The author of binfmt_misc says it
would be useful for Python and elisp, and I've found it convenient to
use it for WINE too.
Now, at the moment, actually using this is rather complicated for both
package maintainers and sysadmins. Maintainers have to cope with the
fact that there's a bug in 2.2/2.3 binfmt_misc (patch sent, and with
luck might make it in before 2.4) which allows you to register two
binary formats with the same name and thus create two files with the
same name in /proc. This needs to be handled consistently across
packages. Sysadmins have to cope with the not-obviously-memorable syntax
of what you have to echo to /proc/sys/fs/binfmt_misc/register to make
the whole thing work.
I've been working on a tool called update-binfmts which, along the same
lines as update-alternatives, dpkg-divert, et al, keeps a database of
binfmt_misc interpreters in /var/lib/dpkg/binfmts, and lets root
register and unregister them at will.
To take WINE as an example of how this might be used, the idea is that,
instead of me using systune to effectively do:
echo ':wine:M::MZ::/usr/bin/wine:' > /proc/sys/fs/binfmt_misc/register
... at startup (without any error-detecting code around this, as I
haven't done the same thing with wine as with javawrapper yet), the wine
package ought to be able to do something in its postinst like:
update-binfmts --package wine --add wine /usr/bin/wine --magic MZ
... and something in its prerm like:
update-binfmts --package wine --remove wine /usr/bin/wine
Then /etc/init.d/binfmt-misc (or similar) does this:
start)
[...]
update-binfmts --register
[...]
;;
stop)
[...]
update-binfmts --unregister
[...]
;;
... to (un)register all installed binary formats with the kernel, and a
sysadmin can do something like 'update-binfmts --register wine' or
'update-binfmts --unregister wine' to turn support for an individual
format on or off.
Obviously this interface is fluid at the moment, but I think it has the
benefit that it's quite close to the syntax used by tools like
dpkg-divert so maintainers should be able to remember it, and it's
almost trivial for an admin. I have a working implementation of
something close to this running on my system, though it needs a few
recent interface changes applied to it and to have its robustness
improved more.
Various issues I thought I ought to take to debian-devel before
proposing this to the dpkg people:
1) Is this a solution in search of a problem? It's certainly a minority
interest. I think that it's a useful feature which is woefully
underused, but some may disagree.
2) Is the interface right? Once it's being used it will be difficult to
change, and particularly as a non-developer I don't want to sound
like I'm imposing my own ideas on everyone. There are several option
switches other than those I've listed above (--offset, --mask, and
--extension) and another action switch (--display).
3) Where should this go? The obvious place is dpkg, but am I being too
arrogant there? It feels too small for its own package, though.
Thanks, and please let me know if you think I'm in over my head,
--
Colin Watson [EMAIL PROTECTED]
