>>>>> > 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:
http://yarchive.net/comp/linux/page_sizes.html
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"
argument?
Gordan
_______________________________________________
arm mailing list
arm@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org
No comments:
Post a Comment