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:
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@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/arm@xxxxxxxxxxxxxxxxxxxxxxx
