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?
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?
bye,
//mirabilos
--
Why don't you use JavaScript? I also don't like enabling JavaScript in
Because I use lynx as browser.
+1
-- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel
