Re: MACH_SEND_MSG_TOO_SMALL is mig breakage (was: Re: current CVS Hurd and glibc (except libthreads)

[Thomas Bushnell, BSG]

Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:

> the "msg too small" is coming from the kernel, and it means that the io_write
> client stub generated a wrong message.  I played a bit with dd and found out
> that this was triggered if more than 2048 bytes were sent at once.

Excellent!  (I was of course mistaking it for a similarly named MIG
error code.)

> Now, let's take a look at how size is calculated:
> 
>         msgh_size_delta = (InP->dataType.msgtl_header.msgt_inline) ?
> (dataCnt + 3) & ~3 : sizeof(char *);
> 
> sizeof(char *) bytes of DATA are used when we don't inline, for the pointer. 
> Otherwise, a multiple of a word bytes of DATA are used to inline.  This is
> what is used from DATA.  Now the whole size:
> 
>         msgh_size = 52 + msgh_size_delta;
> 
> sizeof (mach_msg_header_t) is 24, sizeof (mach_msg_type_long_t) is 12,
> sizeof (mach_msg_type_t) is 4, sizeof (loff_t) is 8.  The total is
> 48 + whatever we use from DATA, not 52 + whatever we use from DATA.
> So MiG miscalculates the size of the message, doesn't it?

Yeah.  The constant is computed inside MiG by just summing up the
sizes of structures itself.  This is actually dangerous, because it
presumes that the sizes will be the same between when MiG runs and
when the header files are included at compile time.  If any of these
structures have changed since when MiG was compiled, then of course
there would be an error.  What MiG *should* do is compute that 52 at
compile time by adding up the sizeofs just as you do in the prose
above.