Re: Recent checkins

[Roland McGrath]

> Right, mach_msg_type_number_t is really not part of the wire protocol
> at all, and my comments don't apply to that.

But some of those natural_t types (including mach_port_name_t) are indeed
part of the "wire" protocol with the kernel.

> Sure, but we're talking about machines where int is 64.

Who is?  I thought we were talking about recent changes, or perhaps changes
likely in the foreseeable future.  Recent changes had to do with the Alpha.
Foreseeable changes have to do with an extant platform.  On every extant
plaform, int is 32 bits.

> On such machines, what do you want the MiG "int" type to refer to?

Such machines would be a good reason to whack on the head anyone who uses
the MiG type "int", unless they really wanted it to be like the C type
int_fast32_t.

> These types are harmless as long as they are restricted in use to the
> presentation and not the wire protocol.

As I said, we have to either compress the Mach interfaces or change them to
avoid having these in the Hurd interfaces as well.  Right now we have
mach_msg_id_t, and maybe some others I haven't noticed.  There are some
.defs files using "int" now that I really think ought to be
mach_msg_type_number_t (you really can do an 8GB io_write on a 64-bit
machine), and then those will be varying as well.  As I said before,
it just seems wrong to penalize 

> In this case, maybe we can drop it entirely.  But there's no going
> back once you are using non-transparent protocols on two machines.

Oh yeah?  We just had a completely incompatible ABI shift, in case you
didn't notice.  The hardest thing to write in we get in these parts is
sandstone, and our tribes can take a little regrinding now and then.  I'm
not trying to be excessively cavalier, but I'm saying that if the system
starts running on the Alpha at all we should all be thrilled, and these
nits can always be rectified later even if it winds up being a bit painful.

Anyway, I think you missed the fundamental point.  I think certain
non-transparencies are not a problem, because the issues can and should be
handled at a protocol-aware layer rather than at a generic message layer.
Intelligent stubs can convert types and diagnose EOVERFLOW and so forth.
Intelligent stubs with fancy presentations that are suboptimal for the
native machine can be generated for when it's worthwhile to support
unnaturally large values.