public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Bart Van Assche <bvanassche@acm.org>
To: "Martin K . Petersen" <martin.petersen@oracle.com>
Cc: linux-scsi@vger.kernel.org, Bart Van Assche <bvanassche@acm.org>,
	Damien Le Moal <dlemoal@kernel.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Randy Dunlap <rdunlap@infradead.org>
Subject: [PATCH v2 07/11] scsi: core: Rename .slave_alloc() and .slave_destroy() in the documentation
Date: Wed,  2 Oct 2024 13:33:59 -0700	[thread overview]
Message-ID: <20241002203528.4104996-8-bvanassche@acm.org> (raw)
In-Reply-To: <20241002203528.4104996-1-bvanassche@acm.org>

Update the SCSI documentation such that it uses the new names for these
methods.

Cc: Damien Le Moal <dlemoal@kernel.org>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
 Documentation/scsi/scsi_mid_low_api.rst | 50 ++++++++++++-------------
 1 file changed, 25 insertions(+), 25 deletions(-)

diff --git a/Documentation/scsi/scsi_mid_low_api.rst b/Documentation/scsi/scsi_mid_low_api.rst
index 2df29b92e196..aba832d590eb 100644
--- a/Documentation/scsi/scsi_mid_low_api.rst
+++ b/Documentation/scsi/scsi_mid_low_api.rst
@@ -112,9 +112,9 @@ Those usages in group c) should be handled with care, especially in a
 that are shared with the mid level and other layers.
 
 All functions defined within an LLD and all data defined at file scope
-should be static. For example the slave_alloc() function in an LLD
+should be static. For example the sdev_prep() function in an LLD
 called "xxx" could be defined as
-``static int xxx_slave_alloc(struct scsi_device * sdev) { /* code */ }``
+``static int xxx_sdev_prep(struct scsi_device * sdev) { /* code */ }``
 
 .. [#] the scsi_host_alloc() function is a replacement for the rather vaguely
        named scsi_register() function in most situations.
@@ -149,18 +149,18 @@ scsi devices of which only the first 2 respond::
     scsi_add_host()  ---->
     scsi_scan_host()  -------+
 			    |
-			slave_alloc()
+			sdev_prep()
 			slave_configure() -->  scsi_change_queue_depth()
 			    |
-			slave_alloc()
+			sdev_prep()
 			slave_configure()
 			    |
-			slave_alloc()   ***
-			slave_destroy() ***
+			sdev_prep()   ***
+			sdev_destroy() ***
 
 
     *** For scsi devices that the mid level tries to scan but do not
-	respond, a slave_alloc(), slave_destroy() pair is called.
+	respond, a sdev_prep(), sdev_destroy() pair is called.
 
 If the LLD wants to adjust the default queue settings, it can invoke
 scsi_change_queue_depth() in its slave_configure() routine.
@@ -176,8 +176,8 @@ same::
     ===----------------------=========-----------------===------
     scsi_remove_host() ---------+
 				|
-			slave_destroy()
-			slave_destroy()
+			sdev_destroy()
+			sdev_destroy()
     scsi_host_put()
 
 It may be useful for a LLD to keep track of struct Scsi_Host instances
@@ -202,7 +202,7 @@ An LLD can use this sequence to make the mid level aware of a SCSI device::
     ===-------------------=========--------------------===------
     scsi_add_device()  ------+
 			    |
-			slave_alloc()
+			sdev_prep()
 			slave_configure()   [--> scsi_change_queue_depth()]
 
 In a similar fashion, an LLD may become aware that a SCSI device has been
@@ -218,12 +218,12 @@ upper layers with this sequence::
     ===----------------------=========-----------------===------
     scsi_remove_device() -------+
 				|
-			slave_destroy()
+			sdev_destroy()
 
 It may be useful for an LLD to keep track of struct scsi_device instances
-(a pointer is passed as the parameter to slave_alloc() and
+(a pointer is passed as the parameter to sdev_prep() and
 slave_configure() callbacks). Such instances are "owned" by the mid-level.
-struct scsi_device instances are freed after slave_destroy().
+struct scsi_device instances are freed after sdev_destroy().
 
 
 Reference Counting
@@ -331,7 +331,7 @@ Details::
     *      bus scan when an HBA is added (i.e. scsi_scan_host()). So it
     *      should only be called if the HBA becomes aware of a new scsi
     *      device (lu) after scsi_scan_host() has completed. If successful
-    *      this call can lead to slave_alloc() and slave_configure() callbacks
+    *      this call can lead to sdev_prep() and slave_configure() callbacks
     *      into the LLD.
     *
     *      Defined in: drivers/scsi/scsi_scan.c
@@ -375,7 +375,7 @@ Details::
     *
     *      Notes: Can be invoked any time on a SCSI device controlled by this
     *      LLD. [Specifically during and after slave_configure() and prior to
-    *      slave_destroy().] Can safely be invoked from interrupt code.
+    *      sdev_destroy().] Can safely be invoked from interrupt code.
     *
     *      Defined in: drivers/scsi/scsi.c [see source code for more notes]
     *
@@ -506,7 +506,7 @@ Details::
     *      Notes: If an LLD becomes aware that a scsi device (lu) has
     *      been removed but its host is still present then it can request
     *      the removal of that scsi device. If successful this call will
-    *      lead to the slave_destroy() callback being invoked. sdev is an
+    *      lead to the sdev_destroy() callback being invoked. sdev is an
     *      invalid pointer after this call.
     *
     *      Defined in: drivers/scsi/scsi_sysfs.c .
@@ -657,9 +657,9 @@ Summary:
   - ioctl - driver can respond to ioctls
   - proc_info - supports /proc/scsi/{driver_name}/{host_no}
   - queuecommand - queue scsi command, invoke 'done' on completion
-  - slave_alloc - prior to any commands being sent to a new device
+  - sdev_prep - prior to any commands being sent to a new device
   - slave_configure - driver fine tuning for given device after attach
-  - slave_destroy - given device is about to be shut down
+  - sdev_destroy - given device is about to be shut down
 
 
 Details::
@@ -960,7 +960,7 @@ Details::
 
 
     /**
-    *      slave_alloc -   prior to any commands being sent to a new device
+    *      sdev_prep -   prior to any commands being sent to a new device
     *                      (i.e. just prior to scan) this call is made
     *      @sdp: pointer to new device (about to be scanned)
     *
@@ -976,12 +976,12 @@ Details::
     *      exist but the mid level is just about to scan for it (i.e. send
     *      and INQUIRY command plus ...). If a device is found then
     *      slave_configure() will be called while if a device is not found
-    *      slave_destroy() is called.
+    *      sdev_destroy() is called.
     *      For more details see the include/scsi/scsi_host.h file.
     *
     *      Optionally defined in: LLD
     **/
-	int slave_alloc(struct scsi_device *sdp)
+	int sdev_prep(struct scsi_device *sdp)
 
 
     /**
@@ -992,7 +992,7 @@ Details::
     *
     *      Returns 0 if ok. Any other return is assumed to be an error and
     *      the device is taken offline. [offline devices will _not_ have
-    *      slave_destroy() called on them so clean up resources.]
+    *      sdev_destroy() called on them so clean up resources.]
     *
     *      Locks: none
     *
@@ -1008,7 +1008,7 @@ Details::
 
 
     /**
-    *      slave_destroy - given device is about to be shut down. All
+    *      sdev_destroy - given device is about to be shut down. All
     *                      activity has ceased on this device.
     *      @sdp: device that is about to be shut down
     *
@@ -1023,12 +1023,12 @@ Details::
     *      by this driver for given device should be freed now. No further
     *      commands will be sent for this sdp instance. [However the device
     *      could be re-attached in the future in which case a new instance
-    *      of struct scsi_device would be supplied by future slave_alloc()
+    *      of struct scsi_device would be supplied by future sdev_prep()
     *      and slave_configure() calls.]
     *
     *      Optionally defined in: LLD
     **/
-	void slave_destroy(struct scsi_device *sdp)
+	void sdev_destroy(struct scsi_device *sdp)
 
 
 

  parent reply	other threads:[~2024-10-02 20:37 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-02 20:33 [PATCH v2 00/11] Improve the "slave" function names Bart Van Assche
2024-10-02 20:33 ` [PATCH v2 01/11] scsi: arcmsr: Remove the changelog Bart Van Assche
2024-10-02 22:28   ` Damien Le Moal
2024-10-02 22:39   ` James Bottomley
2024-10-02 23:47     ` Bart Van Assche
2024-10-02 20:33 ` [PATCH v2 02/11] scsi: ips: " Bart Van Assche
2024-10-02 22:28   ` Damien Le Moal
2024-10-02 20:33 ` [PATCH v2 03/11] scsi: lpfc: " Bart Van Assche
2024-10-02 22:29   ` Damien Le Moal
2024-10-02 20:33 ` [PATCH v2 04/11] scsi: ncr53c8xx: " Bart Van Assche
2024-10-02 22:29   ` Damien Le Moal
2024-10-02 20:33 ` [PATCH v2 05/11] scsi: sym53c8xx: " Bart Van Assche
2024-10-02 22:30   ` Damien Le Moal
2024-10-02 20:33 ` [PATCH v2 06/11] scsi: Rename .slave_alloc() and .slave_destroy() Bart Van Assche
2024-10-02 22:39   ` Damien Le Moal
2024-10-03 21:08     ` Bart Van Assche
2024-10-02 20:33 ` Bart Van Assche [this message]
2024-10-02 20:34 ` [PATCH v2 08/11] scsi: Rename .device_configure() into .sdev_configure() Bart Van Assche
2024-10-02 22:35   ` Damien Le Moal
2024-10-02 20:34 ` [PATCH v2 09/11] scsi: Convert SCSI drivers to .sdev_configure() Bart Van Assche
2024-10-02 22:37   ` Damien Le Moal
2024-10-02 20:34 ` [PATCH v2 10/11] scsi: core: Remove the .slave_configure() method Bart Van Assche
2024-10-02 22:38   ` Damien Le Moal
2024-10-02 20:34 ` [PATCH v2 11/11] scsi: core: Update .slave_configure() references in the documentation Bart Van Assche
2024-10-02 22:38   ` Damien Le Moal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20241002203528.4104996-8-bvanassche@acm.org \
    --to=bvanassche@acm.org \
    --cc=corbet@lwn.net \
    --cc=dlemoal@kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=rdunlap@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox