Re: Recent checkins

[Thomas Bushnell, BSG]

Roland McGrath <roland@frob.com> writes:

> A relevant sample RPC is one that uses integer_t.  integer_t is the signed
> variant of natural_t, and is the Mach type name for the machine's natural
> word size.  But that's only relevant to your comment about integer_t.  Now
> you are talking about int.  The actual changes in question had to do with
> mach_msg_type_number_t, which Mach defines as integer_t.

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

> The fact of the matter is that de facto in this world, short means int16_t,
> int means int32_t, and long is the only one that varies.  I think we should
> stick to purpose-specific type names in MiG .defs files, i.e. uid_t and
> pid_t and off_t so forth.  It would be most clear to define those types in
> hurd_types.defs types with explicit sizes, but the fact that they don't
> vary among extant platforms is all that matters (if that).  (Right now they
> are all defined as int, unsigned or short; those are ambiguous in theory,
> but definitively 32, 32, 16 in practice.)

Sure, but we're talking about machines where int is 64.  On such
machines, what do you want the MiG "int" type to refer to?  If it refers
to 32 bits, then it is inconsistent with the C "int" type on such
machines.  If it refers to 64 bits, then no network transparent
protocols can use the type.  So the best thing is to never use the
type (which means what we should really do is change
<hurd/hurd_types.defs> and all the Mach interfaces to avoid the
non-bit-specific type names.

> The MiG presentations themselves use types such as mach_msg_type_number_t
> and mach_msg_id_t, which vary by machine (i.e. it's natural_t).  

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

> Some of
> our interfaces (including struct layouts) that refer to values from Mach
> use those types as well, and so vary by machine.  That's just the way the
> cookie crumbles if we want to refer to the natural uninterpreted Mach
> values instead of having a widened universal set of constants in all our
> interfaces.

The struct layouts have to be kept track of in machine-independent
format.  Right now those things are pretty insane.

> I frankly am not real concerned about this question of type sizes matching
> up on different machines.  If we ever have a netmsgserver kind of reality,
> I find it entirely acceptable for it to be based on the OSFMach style of
> "self-describing to receiver" instead of "self describing to transport".
> (That style seems the only thing anyone would consider implementing on an
> IPC system like L4's.)  

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.

Thomas