|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [PATCH v2] docs: update xenstore-migration.md
> -----Original Message----- > From: Xen-devel <xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx> On Behalf Of Juergen > Gross > Sent: 28 May 2020 09:22 > To: xen-devel@xxxxxxxxxxxxxxxxxxxx > Cc: Juergen Gross <jgross@xxxxxxxx>; Stefano Stabellini > <sstabellini@xxxxxxxxxx>; Julien Grall > <julien@xxxxxxx>; Wei Liu <wl@xxxxxxx>; Andrew Cooper > <andrew.cooper3@xxxxxxxxxx>; Ian Jackson > <ian.jackson@xxxxxxxxxxxxx>; George Dunlap <george.dunlap@xxxxxxxxxx>; Jan > Beulich <jbeulich@xxxxxxxx> > Subject: [PATCH v2] docs: update xenstore-migration.md > > Update connection record details: make flags common for sockets and > domains, and add pending incoming data. > > Signed-off-by: Juergen Gross <jgross@xxxxxxxx> > --- > V2: > - added out-resp-len to connection record > --- > docs/designs/xenstore-migration.md | 71 +++++++++++++++++------------- > 1 file changed, 40 insertions(+), 31 deletions(-) > > diff --git a/docs/designs/xenstore-migration.md > b/docs/designs/xenstore-migration.md > index 34a2afd17e..5736bbad94 100644 > --- a/docs/designs/xenstore-migration.md > +++ b/docs/designs/xenstore-migration.md > @@ -147,43 +147,59 @@ the domain being migrated. > ``` > 0 1 2 3 4 5 6 7 octet > +-------+-------+-------+-------+-------+-------+-------+-------+ > -| conn-id | conn-type | conn-spec > +| conn-id | conn-type | flags | > ++-------------------------------+---------------+---------------+ > +| conn-spec > ... > -+-------------------------------+-------------------------------+ > -| data-len | data > -+-------------------------------+ > ++---------------+---------------+-------------------------------+ > +| in-data-len | out-resp-len | out-data-len | > ++---------------+---------------+-------------------------------+ > +| data > ... > ``` > > > -| Field | Description | > -|-------------|-------------------------------------------------| > -| `conn-id` | A non-zero number used to identify this | > -| | connection in subsequent connection-specific | > -| | records | > -| | | > -| `conn-type` | 0x0000: shared ring | > -| | 0x0001: socket | > -| | 0x0002 - 0xFFFF: reserved for future use | > -| | | > -| `conn-spec` | See below | > -| | | > -| `data-len` | The length (in octets) of any pending data not | > -| | yet written to the connection | > -| | | > -| `data` | Pending data (may be empty) | > +| Field | Description | > +|----------------|----------------------------------------------| > +| `conn-id` | A non-zero number used to identify this | > +| | connection in subsequent connection-specific | > +| | records | > +| | | > +| `flags` | A bit-wise OR of: | > +| | 0001: read-only | > +| | | > +| `conn-type` | 0x0000: shared ring | > +| | 0x0001: socket | > +| | 0x0002 - 0xFFFF: reserved for future use | > +| | | Agreed with Julien... the above two would be better swapped to match the order of the fields in the record. > +| `conn-spec` | See below | > +| | | > +| `in-data-len` | The length (in octets) of any data read | > +| | from the connection not yet processed | > +| | | > +| `out-resp-len` | The length (in octets) of a partial response | > +| | not yet written to the connection (included | > +| | in the following `out-data-len`) | > +| | | > +| `out-data-len` | The length (in octets) of any pending data | > +| | not yet written to the connection | So, IIUC out-data-len is inclusive of out-resp-len? > +| | | > +| `data` | Pending data, first read data, then written | > +| | data (any of both may be empty) | Perhaps be more explicit here: "Pending data: first in-data-len octets of read data, then out-data-len octets of written data" > > -The format of `conn-spec` is dependent upon `conn-type`. > +In case of live update the connection record for the connection via which > +the live update command was issued will contain the response for the live > +update command in the pending write data. s/write/written for consistency I think. Paul > > \pagebreak > > +The format of `conn-spec` is dependent upon `conn-type`. > + > For `shared ring` connections it is as follows: > > > ``` > 0 1 2 3 4 5 6 7 octet > - +-------+-------+ > - | flags | > +---------------+---------------+---------------+---------------+ > | domid | tdomid | evtchn | > +-------------------------------+-------------------------------+ > @@ -198,8 +214,6 @@ For `shared ring` connections it is as follows: > | | it has been subject to an SET_TARGET | > | | operation [2] or DOMID_INVALID [3] otherwise | > | | | > -| `flags` | Must be zero | > -| | | > | `evtchn` | The port number of the interdomain channel used | > | | by `domid` to communicate with xenstored | > | | | > @@ -211,8 +225,6 @@ For `socket` connections it is as follows: > > > ``` > - +-------+-------+ > - | flags | > +---------------+---------------+---------------+---------------+ > | socket-fd | pad | > +-------------------------------+-------------------------------+ > @@ -221,9 +233,6 @@ For `socket` connections it is as follows: > > | Field | Description | > |-------------|-------------------------------------------------| > -| `flags` | A bit-wise OR of: | > -| | 0001: read-only | > -| | | > | `socket-fd` | The file descriptor of the connected socket | > > This type of connection is only relevant for live update, where the xenstored > @@ -398,4 +407,4 @@ explanation of node permissions. > > [3] See > https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/xen.h;hb=HEAD#l612 > > -[4] https://wiki.xen.org/wiki/XenBus > \ No newline at end of file > +[4] https://wiki.xen.org/wiki/XenBus > -- > 2.26.2 >
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |