Re: Plan needed for switching m68k to 32-bit alignment

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

 




On 28/10/24 13:19, Thorsten Glaser wrote:
On Sun, 27 Oct 2024, Arnd Bergmann wrote:

I think it makes sense to go through these anyway and annotate
them to document and enforce the alignment we actually want

That would be good in general, yes. I’d personally argue for
using explicit padding members (please do NOT use __unused,
rather __pad1 __pad2 etc. or __unused1, etc. as __unused is
used (hah) by BSD code for the GCC attribute a lot) and in
cases where nōn-natural alignment is needed, GCC __packed__
plus explicit padding. That is easier to read than __aligned__.

TIL that GCC has a __warn_if_not_aligned__ attribute now,
which could be useful, but mostly for the code that makes
these assumptions, so not us here.

padding. If all of them get fixed alignment, this would allow
switching -malign-int on independently for userspace and
kernel without changing the ABI. Any duplicated copies of
the struct definitions in userspace of course would need
the same changes.

That is… an interesting side effect and probably a good idea
to decouple this… unless there are any *other* kernel-side
changes we absolutely need for this that we don’t want to put
atop via evolution, not revolution (i.e. whether there is any‐
thing in the kernel/userspace boundary that direly needs to
change, for this or anyway, and is a breaking change… though
maybe even then).


On Sun, 27 Oct 2024, Greg Ungerer wrote:
There is plenty of Linux on ColdFire, but all the m68k'isms apply the same.

Ah, okay. All of it nommu though?

No, there is a few ColdFire family members with MMU, specifically the version 4
core parts (547x, 548x, 5441x and 5445x). All supported by Linux, and popular
with some because they are significantly faster then the 68060. I regularly
(as in every mainline rc and kernel release) test on the 5475, and recently I
was sent a 54418 board and test on that now too.

To be fair though I build complete embedded systems and don't generally rely
on distros for a user space. So a flag day API change would not bother me at all.
That may well not be true for all ColdFire users though.


Is there anything special we need to do or must not to that
relates to ColdFire? Anyone to put in the Cc list for that?

Nothing special or different that I can think of. The struct alignment used
is the same as for standard m68k, so the problem is the same. The only user
space visible differences I can think of is the slight difference in layout
for the ptrace pt_regs struct. And those elements are probably problematic with
the mix of bit fields short/long at the end.

Regards
Greg





[Index of Archives]     [Video for Linux]     [Yosemite News]     [Linux S/390]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux