Bug 382723 – sys-apps/openrc: support /etc/binfmt.d/

• Product: Gentoo Hosted Projects
• Status: RESOLVED FIXED

[Description Michał Górny 2011-09-12 16:58:21 UTC]

Right now, Gentoo packages adding support for binaries via binfmt_misc usually install complex init.d scripts which mount binfmt_misc if necessary and add their entry.

This could be simplified if OpenRC introduced a common script mounting binfmt_misc, grabbing all necessary entries and pushing them into binfmt_misc.

To avoid reinventing the wheel completely, we could reuse the concept of binfmt.d used in systemd.

systemd uses three directories for those config files (in order):
- /usr/lib/binfmt.d
- /etc/binfmt.d
- /run/binfmt.d

Files in those directories need to have '.conf' suffix, and if two files of the same name appear in two of these directories, the latter one takes precedence (i.e. only one of them is actually used).

As for the file syntax, it is very simple. '#' and ';' denote comments and are ignored. Remaining lines are directly echoed into binfmt_misc/register (i.e. has the same format as regular entry).

[Comment 1 Michał Górny 2011-09-12 16:59:06 UTC]

Ah, and a particular example consumer would be dev-dotnet/pe-format which would happily drop its long and boring init.d script.

[Comment 2 SpanKY 2011-09-15 04:19:55 UTC]

/etc/binfmt.d/ sounds find.  i wanted this in the past on my own machines for use with qemu ...

not sure we need to split binfmt_misc out of the existing procfs script though

[Comment 3 Michał Górny 2011-09-15 08:48:55 UTC]

Created attachment 286533 [details, diff]
Patch adding a simple script for it

It should basically do the thing; I don't have any OpenRC machine to test it.

[Comment 4 SpanKY 2011-09-17 05:12:27 UTC]

Comment on attachment 286533 [details, diff]
Patch adding a simple script for it

looks way more complicated than necessary.  one liner to add to procfs:
grep -qsv -e '^[#;]' -e '^[[:space:]]*$' \
    /run/binfmt.d/*.conf \
    "@SYSCONFDIR@"/binfmt.d/*.conf \
    "@PREFIX@"/usr/lib/binfmt.d/*.conf \
    > /proc/sys/fs/binfmt_misc/register

[Comment 5 Michał Górny 2011-09-18 12:35:50 UTC]

(In reply to comment #4)
> Comment on attachment 286533 [details, diff]
> Patch adding a simple script for it
> 
> looks way more complicated than necessary.  one liner to add to procfs:
> grep -qsv -e '^[#;]' -e '^[[:space:]]*$' \
>     /run/binfmt.d/*.conf \
>     "@SYSCONFDIR@"/binfmt.d/*.conf \
>     "@PREFIX@"/usr/lib/binfmt.d/*.conf \
>     > /proc/sys/fs/binfmt_misc/register

Issues with your solution:
1) no sane error handling,
2) no possibility of filtering duplicate files,
3) no possibility of disabling/reloading binfmt.d rules.

[Comment 6 SpanKY 2011-09-18 19:25:34 UTC]

(In reply to comment #5)

(1) you write an error in your config file, it's your fault
(2) yours didn't handle duplicates either, but i'm not sure it's really necessary at this point
(3) true, but yours lacks any restart support as well, and doing it cleanly is non-trivial to the point where i'm not sure it's worth it: clobbering all registrations at restart time (write -1 to status) is unacceptable; cleanly maintaining a list of registered handlers at start time and removing them at stop time is non-trivial and unsure if that's really what the user wants

further, on the duplicate side, i dont see the point of handling any dir beyond /etc/binfmt.d/, and no one will be installing files into that that are unconditionally enabled.  so if the user enables a duplicate, well that's a user error.

we can ship this now and see if anyone complains.  if no one does, then obviously it's not that big of a deal.

[Comment 7 Michał Górny 2011-09-18 19:38:09 UTC]

(In reply to comment #6)
> further, on the duplicate side, i dont see the point of handling any dir beyond
> /etc/binfmt.d/, and no one will be installing files into that that are
> unconditionally enabled.  so if the user enables a duplicate, well that's a
> user error.

That was intended for compatibility with systemd. There's no reason to re-invent the same thing just for the sake of reinvention. And /usr location is much better for apps to install those descriptions than /etc. I wouldn't treat them as config file.

[Comment 8 SpanKY 2011-09-18 20:07:37 UTC]

packages don't get to decide what random files are now executable ... users do.  i'll leave in the additional paths for now to see what kind of hell breaks loose.

http://git.overlays.gentoo.org/gitweb/?p=proj/openrc.git;a=commitdiff;h=47d305d2af41a6105824bd704a0f0f958b35871d