2019/3/11 a las 14:36, Laurent Vivier: > On 11/03/2019 14:29, Unai Martinez Corral wrote: > > 2019/3/11 12:14, Laurent Vivier: > >> On 11/03/2019 11:30, Unai Martinez-Corral wrote: > > > >>> +-s|--systemd: don't write into /proc, generate > >>> file(s) for > >>> + systemd-binfmt.service; > >>> environment variable HOST_ARCH > >> > >> why HOST_ARCH appears here? > > > > The existing comment seems to be specific to systemd: > > https://github.com/qemu/qemu/blob/master/scripts/qemu-binfmt-conf.sh#L201-L204 > > 'systemd' is the single mode in which it makes sense to generate a > > bunch of configuration files for a different architecture than the > > current one, isn't it? > > No, it's not specific to systemd. If we register an interpreter for the > current architecture we can make it unusable.
I think we are not understanding each other in this point: The comment about HOST_ARCH in the current master branch is as follows: > With systemd, binfmt files are loaded by systemd-binfmt.service > > The environment variable HOST_ARCH allows to override 'uname' to generate configuration files for a different architecture than the current one. That's why I assumed that the envvar is meant to be used with systemd only. Certainly, withou systemd no configuration files are generated at all; interpreters are directly registered/configured. However, the implementation takes HOST_ARCH into account with no regard to 'systemd' or 'debian'. It is used unconditionally. This has been like this since the base of the current script was pushed in 2016/1/29. So, what is your proposal? - Move the comment below, as it was before. - Add a patch to only take HOST_ARCH into account for systemd (and debian?) - Remove HOST_ARCH and the comment from the script (and take it back if you patch to the kernel is accepted some day). I will wait to sort this out before pushing v5. I think that all the remaining issues are addressed already: https://github.com/umarcor/qemu/blob/series-qemu-binfmt-conf/scripts/qemu-binfmt-conf.sh Regards, Unai
