| Message ID | 166012881358.10085.7894829376842264679.stgit@orion (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | xfsdump: Remove remaining 'slave' wording from xfsdump | expand |
On Wed, Aug 10, 2022 at 12:53:33PM +0200, Carlos Maiolino wrote: > While we've already removed the word 'slave' from the code, the > documentation should still be updated. > > Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com> Looks good, Reviewed-by: Darrick J. Wong <djwong@kernel.org> --D > --- > doc/xfsdump.html | 38 +++++++++++++++++++------------------- > 1 file changed, 19 insertions(+), 19 deletions(-) > > diff --git a/doc/xfsdump.html b/doc/xfsdump.html > index e37e362..2faa65e 100644 > --- a/doc/xfsdump.html > +++ b/doc/xfsdump.html > @@ -286,7 +286,7 @@ of a dump/restore session to multiple drives. > | | | > 4. O O O ring buffers common/ring.[ch] > | | | > -5. slave slave slave ring_create(... ring_slave_entry ...) > +5. worker worker worker ring_create(... ring_worker_entry ...) > thread thread thread > | | | > 6. drive drive drive physical drives > @@ -306,7 +306,7 @@ The process hierachy is shown above. main() first initialises > the drive managers with calls to the drive_init functions. In > addition to choosing and assigning drive strategies and ops for each > drive object, the drive managers intialise a ring buffer and (for > -devices other than simple UNIX files) sproc off a slave thread that > +devices other than simple UNIX files) sproc off a worker thread that > that handles IO to the tape device. This initialisation happens in the > drive_manager code and is not directly visible from main(). > <p> > @@ -316,31 +316,31 @@ sprocs. Each child begins execution in childmain(), runs either > content_stream_dump or content_stream_restore and exits with the > return code from these functions. > <p> > -Both the stream manager processes and the drive manager slaves > +Both the stream manager processes and the drive manager workers > set their signal disposition to ignore HUP, INT, QUIT, PIPE, > ALRM, CLD (and for the stream manager TERM as well). > <p> > -The drive manager slave processes are much simpler, and are > +The drive manager worker processes are much simpler, and are > initialised with a call to ring_create, and begin execution in > -ring_slave_func. The ring structure must also be initialised with > +ring_worker_func. The ring structure must also be initialised with > two ops that are called by the spawned thread: a ring read op, and a write op. > The stream manager communicates with the tape manager across this ring > structure using Ring_put's and Ring_get's. > <p> > -The slave thread sits in a loop processing messages that come across > +The worker thread sits in a loop processing messages that come across > the ring buffer. It ignores signals and does not terminate until it > receives a RING_OP_DIE message. It then exits 0. > <p> > The main process sleeps waiting for any of its children to die > (ie. waiting for a SIGCLD). All children that it cares about (stream > -managers and ring buffer slaves) are registered through the child > +managers and ring buffer workers) are registered through the child > manager abstraction. When a child dies wait status and other info is > stored with its entry in the child manager. main() ignores the deaths > of children (and grandchildren) that are not registered through the child > manager. The return status of these subprocesses is checked > and in the case of an error is used to determine the overall exit code. > <p> > -We do not expect slave threads to ever die unexpectedly: they ignore > +We do not expect worker threads to ever die unexpectedly: they ignore > most signals and only exit when they receive a RING_OP_DIE at which > point they drop out of the message processing loop and always signal success. > <p> > @@ -1680,35 +1680,35 @@ If xfsdump/xfsrestore is running single-threaded (-Z option) > or is running on Linux (which is not multi-threaded) then > records are read/written straight to the tape. If it is running > multi-threaded then a circular buffer is used as an intermediary > -between the client and slave threads. > +between the client and worker threads. > <p> > Initially <i>drive_init1()</i> calls <i>ds_instantiate()</i> which > if dump/restore is running multi-threaded, > creates the ring buffer with <i>ring_create</i> which initialises > -the state to RING_STAT_INIT and sets up the slave thread with > -ring_slave_entry. > +the state to RING_STAT_INIT and sets up the worker thread with > +ring_worker_entry. > <pre> > ds_instantiate() > ring_create(...,ring_read, ring_write,...) > - allocate and init buffers > - set rm_stat = RING_STAT_INIT > - start up slave thread with ring_slave_entry > + start up worker thread with ring_worker_entry > </pre> > -The slave spends its time in a loop getting items from the > +The worker spends its time in a loop getting items from the > active queue, doing the read or write operation and placing the result > back on the ready queue. > <pre> > -slave > +worker > ====== > -ring_slave_entry() > +ring_worker_entry() > loop > - ring_slave_get() - get from active queue > + ring_worker_get() - get from active queue > case rm_op > RING_OP_READ -> ringp->r_readfunc > RING_OP_WRITE -> ringp->r_writefunc > .. > endcase > - ring_slave_put() - puts on ready queue > + ring_worker_put() - puts on ready queue > endloop > </pre> > > @@ -1778,7 +1778,7 @@ prepare_drive() > <p> > For each <i>do_read</i> call in the multi-threaded case, > we have two sides to the story: the client which is coming > -from code in <i>content.c</i> and the slave which is a simple > +from code in <i>content.c</i> and the worker which is a simple > thread just satisfying I/O requests. > From the point of view of the ring buffer, these are the steps > which happen for reading: > @@ -1786,7 +1786,7 @@ which happen for reading: > <li>client removes msg from ready queue > <li>client wants to read, so sets op field to READ (RING_OP_READ) > and puts on active queue > -<li>slave removes msg from active queue, > +<li>worker removes msg from active queue, > invokes client read function, > sets status field: OK/ERROR, > puts msg on ready queue > >
diff --git a/doc/xfsdump.html b/doc/xfsdump.html index e37e362..2faa65e 100644 --- a/doc/xfsdump.html +++ b/doc/xfsdump.html @@ -286,7 +286,7 @@ of a dump/restore session to multiple drives. | | | 4. O O O ring buffers common/ring.[ch] | | | -5. slave slave slave ring_create(... ring_slave_entry ...) +5. worker worker worker ring_create(... ring_worker_entry ...) thread thread thread | | | 6. drive drive drive physical drives @@ -306,7 +306,7 @@ The process hierachy is shown above. main() first initialises the drive managers with calls to the drive_init functions. In addition to choosing and assigning drive strategies and ops for each drive object, the drive managers intialise a ring buffer and (for -devices other than simple UNIX files) sproc off a slave thread that +devices other than simple UNIX files) sproc off a worker thread that that handles IO to the tape device. This initialisation happens in the drive_manager code and is not directly visible from main(). <p> @@ -316,31 +316,31 @@ sprocs. Each child begins execution in childmain(), runs either content_stream_dump or content_stream_restore and exits with the return code from these functions. <p> -Both the stream manager processes and the drive manager slaves +Both the stream manager processes and the drive manager workers set their signal disposition to ignore HUP, INT, QUIT, PIPE, ALRM, CLD (and for the stream manager TERM as well). <p> -The drive manager slave processes are much simpler, and are +The drive manager worker processes are much simpler, and are initialised with a call to ring_create, and begin execution in -ring_slave_func. The ring structure must also be initialised with +ring_worker_func. The ring structure must also be initialised with two ops that are called by the spawned thread: a ring read op, and a write op. The stream manager communicates with the tape manager across this ring structure using Ring_put's and Ring_get's. <p> -The slave thread sits in a loop processing messages that come across +The worker thread sits in a loop processing messages that come across the ring buffer. It ignores signals and does not terminate until it receives a RING_OP_DIE message. It then exits 0. <p> The main process sleeps waiting for any of its children to die (ie. waiting for a SIGCLD). All children that it cares about (stream -managers and ring buffer slaves) are registered through the child +managers and ring buffer workers) are registered through the child manager abstraction. When a child dies wait status and other info is stored with its entry in the child manager. main() ignores the deaths of children (and grandchildren) that are not registered through the child manager. The return status of these subprocesses is checked and in the case of an error is used to determine the overall exit code. <p> -We do not expect slave threads to ever die unexpectedly: they ignore +We do not expect worker threads to ever die unexpectedly: they ignore most signals and only exit when they receive a RING_OP_DIE at which point they drop out of the message processing loop and always signal success. <p> @@ -1680,35 +1680,35 @@ If xfsdump/xfsrestore is running single-threaded (-Z option) or is running on Linux (which is not multi-threaded) then records are read/written straight to the tape. If it is running multi-threaded then a circular buffer is used as an intermediary -between the client and slave threads. +between the client and worker threads. <p> Initially <i>drive_init1()</i> calls <i>ds_instantiate()</i> which if dump/restore is running multi-threaded, creates the ring buffer with <i>ring_create</i> which initialises -the state to RING_STAT_INIT and sets up the slave thread with -ring_slave_entry. +the state to RING_STAT_INIT and sets up the worker thread with +ring_worker_entry. <pre> ds_instantiate() ring_create(...,ring_read, ring_write,...) - allocate and init buffers - set rm_stat = RING_STAT_INIT - start up slave thread with ring_slave_entry + start up worker thread with ring_worker_entry </pre> -The slave spends its time in a loop getting items from the +The worker spends its time in a loop getting items from the active queue, doing the read or write operation and placing the result back on the ready queue. <pre> -slave +worker ====== -ring_slave_entry() +ring_worker_entry() loop - ring_slave_get() - get from active queue + ring_worker_get() - get from active queue case rm_op RING_OP_READ -> ringp->r_readfunc RING_OP_WRITE -> ringp->r_writefunc .. endcase - ring_slave_put() - puts on ready queue + ring_worker_put() - puts on ready queue endloop </pre> @@ -1778,7 +1778,7 @@ prepare_drive() <p> For each <i>do_read</i> call in the multi-threaded case, we have two sides to the story: the client which is coming -from code in <i>content.c</i> and the slave which is a simple +from code in <i>content.c</i> and the worker which is a simple thread just satisfying I/O requests. From the point of view of the ring buffer, these are the steps which happen for reading: @@ -1786,7 +1786,7 @@ which happen for reading: <li>client removes msg from ready queue <li>client wants to read, so sets op field to READ (RING_OP_READ) and puts on active queue -<li>slave removes msg from active queue, +<li>worker removes msg from active queue, invokes client read function, sets status field: OK/ERROR, puts msg on ready queue
While we've already removed the word 'slave' from the code, the documentation should still be updated. Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com> --- doc/xfsdump.html | 38 +++++++++++++++++++------------------- 1 file changed, 19 insertions(+), 19 deletions(-)