qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v4 7/10] qemu-binfmt-conf.sh: generalize CPU to


From: Laurent Vivier
Subject: Re: [Qemu-devel] [PATCH v4 7/10] qemu-binfmt-conf.sh: generalize CPU to positional TARGETS
Date: Mon, 11 Mar 2019 20:26:45 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

On 11/03/2019 20:23, Unai Martinez Corral wrote:
> 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.

Yes, move the comment below as it was before.

Thanks,
LAurent



reply via email to

[Prev in Thread] Current Thread [Next in Thread]