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

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