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)
next prev 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