[Top][All Lists]

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

Re: [PATCH 10/15] x86_64: expand and shrink messages in copy{in, out}msg

From: Luca
Subject: Re: [PATCH 10/15] x86_64: expand and shrink messages in copy{in, out}msg routines
Date: Tue, 4 Oct 2022 22:39:03 +0200

Il 30/08/22 07:57, Luca ha scritto:
Il 28/08/22 15:13, Samuel Thibault ha scritto:

+                }
+              else
+                {
+                  size_t n = size / 8;
+                  saddr += n*number;
+                  usize += n*number;
+                  align_inline(saddr, 4);
+                  align_inline(usize, 4);

This should be alignof(some_align_type)

Will do.

Thinking about it, I'm not sure about alignof(). For example, if I add something like

#define MACH_MSG_ALIGNMENT alignof(rpc_vm_offset_t)

then I'm assuming that the alignment of a data type with a given size is the same on 32-bit and 64-bit variants. While this is true on x86 up to 4-byte size, it's not true for 8-byte size. Specifically, on 32-bit this would be

#define MACH_MSG_ALIGNMENT alignof(unsigned long)

while on 64-bit it would be

#define MACH_MSG_ALIGNMENT alignof(unsigned int)

Currently the copy_user.c file is only compiled on 64-bit, but I suppose this definition would be useful in other places, not 64-bit specific, and also in mig (and also if one day gnumach supports non-x86 :))

For me it would be less confusing to just define it as 4. As far as I understand it's the default alignment of structure fields on the 32-bit variant (from how mig works), and it seems a bit "forced" to try to derive this value on a 64-bit variant. By the way, the rpc code generated by mig now forces this alignment, so the reason to have it seems mostly backwards compatibility.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]