:...
:jrecord_init(jo, &jrec, JREC_STREAMID_DISCONT);
:jrecord_write(&jrec, JTYPE_ASSOCIATE, 0);
:...
:
:
:1) the `streamid' parameter for jrecord_init() is set to
: JREC_STREAMID_DISCONT which is defined as 0x0002.
:
: While in function jrecord_init():
:
: ...
: if (streamid < 0) {
: streamid = sid++; /* XXX need to track stream ids! */
: if (sid == JREC_STREAMID_JMAX)
: sid = JREC_STREAMID_JMIN;
: }
: jrec->streamid = streamid;
: ...
:
: So now jrec->streamid is JREC_STREAMID_DISCONT (0x0002).
:
: Shouldn't streamid be some number between JREC_STREAMID_JMIN and
: JREC_STREAMID_JMAX?
:
:#define JREC_STREAMID_JMIN 0x0100 /* lowest allowed general id */
:#define JREC_STREAMID_JMAX 0x2000 /* (one past the highest allowed id) */
:...
:Thanks,
:
:Rongsheng
It's a work in progress! :-) Basically the idea with the 0x0100-0x2000
was that those stream ID's would represent transactions that potentially
run in parallel, whos contents are in the subrecord format. These
ID's would be short-lived and 'reusable' meaning that the ID's have no
special meaning and could be reusable after the transaction completes.
Id's below 0x0100 contain out of band data that is not necessarily
in the subrecord format and not necessarily bound by the transaction
rules used by the main ID set. So, e.g. system time stamps, a heartbeat
record, text annotations issued by the system operator via mountctl, and
other things.
This might not be the best way to organize the structure... the subrecord
data format is nicely abstracted and I might wind up using it inside all
the stream records. I haven't decided yet.
-Matt
Matthew Dillon
<dillon at xxxxxxxxxxxxx>