Wednesday, April 27, 2016

[fedora-arm] Re: armhf dnf is not working on aarch64 kernel

On 2016-04-27 14:45, Peter Robinson wrote:
>>>>> > I want to use the armhf fedora rootfs on the aarch64 bit kernel.
>>>>> You can't, it's not a use case we support.
>>>> Why not? All arm binaries can be runnable on aarch32 mode of aarch64
>>>> kernel.
>>> Not exactly actually, it's possible to have aarch64/ARMv8 CPUs that
>>> don't have the 32 bit components.
>> That this is not the case here, though. So the answer doesn't seem
>> to answer the question.
> Actually it does answer the question. The question is about "32 bit
> binaries on aarch64" and there are cases when they can't run.

And that justified not caring about all other cases?

>>>>> > The question is 'how can I run 'dnf' command on armhf fedora with
>>>>> > aarch64 kernel?'
>>>>> No, the ARMv7 and aarch64 ABI aren't compatible, the only way we
>>>>> support ARMv7 on aarch64 is via virtualisation. We will not be
>>>>> supporting this or a "multilib" usecase.
>>>> The aarch64 kernel can execute both aarch64 and aarch32(fully
>>>> compatible
>>>> armv7) binaries. For example, the kernel of raspberry pi 3 is
>>>> aarch64 and
>>>> fedora arm version can't run on rpi3. Even all binaries can run on
>>>> it but
>>>> only dnf command can't do that.
>>> Actually that isn't entirely true. The kernel that's currently
>>> shipped
>>> in raspbian for RPi3 is actually an ARMv7 kernel where the firmware
>>> boots the ARM cores as v7 cores. The kernel code that's running there
>>> is ARMv7 code not cortex-a53 code paths. That is a fairly special
>>> usecase and you can actually do that on Fedora ARMv7 with a Fedora
>>> ARMv7 kernel, not a aarch64 kernel.
>> Again, this doesn't answer the question and ignored the most obvious
>> and common case, where we have ARMv8 hardware (e.g. X-Gene) that fully
>> supports ARMv7 instruction set for backward compatibility, running an
>> aarch64 kernel with 4KB memory pages (the sensible size) and backward
>> compatibility option enabled (no detriment to doing so).
> What about Seattle that explicitly needs a kernel with 64K pages?

Does one broken implementation justify a decision detrimental to
all other uses? Linus himself has had some choice words over time
about defaulting to large pages:

Are there some specific new developments that fundamentally
deprecate those words of wisdom?

Additionally, are you saying that 64KB page size support
is mandatory on ARMv8 but 4KB is not? I cannot seem to find
any documentation from ARM stating this explicitly, the closest
I can find is that either/both can be available.

>> You can then run an armv7hl (or armv5tel) userspace in a chroot with
>> no ill effects. I run a setup like this where I run hard-float and
>> soft-float 32-bit userspace docker containers even though the host
>> userspace and kernels are aarch64. I see no sane reason why this
>> would not be a supported configuration, since the usefulness of it
>> seems very obvious.
> Sure, but we made a decision that our kernels would be 64K pages on
> aarch64 some time ago. We need to make a decision that is not easy to
> change to be compatible moving forward for a new architecture that is
> evolving. Sure right at THIS VERY MOMENT the hardware that YOU'RE
> using might support that configuration but there is HW that is
> available right now that needs a configuration that you don't
> currently have and there could well be HW soon (I don't know, and if I
> did it's very likely I couldn't comment anyway) that doesn't have the
> optional bits needed for aarch32.

And the advantage of not anti-supporting it while and where
it is available is?

> So while it's easy to say "it works for me" sure, you can hack things
> how ever you like and sit back from the edges commenting, we need to
> make a decisions such as page sizes that we'll need to support for
> years to come based on the information we have at the time. Other
> distros have made similar decisions, others haven't, that's their
> choices.

Decisions to support for years on a distro with an estimated 13
month shelf life?

> Either way if you need to build a custom kernel for a ARMv7 userspace
> it's up to you and that use case is fine, it's your decision to make.
>>> ARM multilib is something we explicitly decided not to support when
>>> we
>>> were dealing with that. Multilib is a mess on x86, it's not a mess we
>>> need on ARM.
>> We aren't talking about multilib here, we are talking about
>> chroots/containers which are a very separate use case.
> It might be a separate usecase but it doesn't make it less relevant
> for reasons why we don't support the usecase.

If it is because ARM32 support is optional in ARMv8, then why
bring up multilib at all?

>> But since you mentioned it, if we don't have multilib because it's
>> a mess, why is it that aarch64 Fedora still uses lib64 rather than
>> lib directories? I don't see how this is less of a mess than what
> Because lib64 is a directory that all current 64 bit architectures
> that Fedora supports uses. It's about consistency rather than
> multilib.

How is dnf being the seemingly only thing that breaks in this
case while all other binaries work fine in line with the "consistency"

arm mailing list

No comments:

Post a Comment