Virtual structs are prefaced with a header, which consists of
the following, in order:
-1. 128-bit GUID of the most derived vstruct type
-2. 160-bit SHA-1 of the vstruct type info
-3. 32-bit objlist-offset of an introspection object
-4. 32-bit length of vstruct, including header, and all referenced
+1. 32-bit length of vstruct, including header, and all referenced
data chunks, which must be contiguously appended to the vstruct body
-5. 32-bit reserved field
+2. 32-bit offset of start of actual struct
+3. 128-bit GUID of the most derived vstruct type
+5. 32-bit objlist-offset of the vstruct's object handles, the first
+of which is introspection object
+6. 32-bit length of vstruct objlist in handles
+7. 32-bit offset of an area within the vstruct where the objlist can
+be copied.
+8. 32-bit reserved field
The requirement for all referenced data chunks to be contiguous with
the vstruct means that scatter-gather and zero-copy cannot be done;
process that does know the derived type). For this reason, vstructs
should generally not be used to pass large chunks of data.
-The introspection object reference may be NULL; in this case, the
-SHA-1 field is ignored.
+Likewise, object handles must be preserved even if they are only
+referenced in an unknown-type portion of the vstruct. To facilitate
+this, all handles referenced from the vstruct must be contiguous in
+the objlist (even if this means duplications), and there must be an
+area in the vstruct blob where unmarshalling code can copy the
+translated objlist.
+
+The introspection object reference at the beginning of the vstruct
+objlist may be NULL.
Op1: Get Interface List
-----------------------
projects / polintos / scott / priv.git / blobdiff