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

[Luca]

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.

Luca