Add Documentation/DocBook/scsi_midlayer.tmpl and add to Makefile.
Subsystems (3)
PATCH 15/15 Add Documentation/DocBook/scsi_midlayer.tmpl and add to Makefile.
From: Rob Landley <[email protected]>
Add Documentation/DocBook/scsi_midlayer.tmpl and add to Makefile.
---
Documentation/DocBook/Makefile | 2 Documentation/DocBook/scsi_midlayer.tmpl | 409 +++++++++++++++++++++ 2 files changed, 410 insertions(+), 1 deletion(-)
Documentation/DocBook/scsi_midlayer.tmpl new file +409 -0
@@ -0,0 +1,409 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" + "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []> + +<book id="scsimid"> + <bookinfo> + <title>SCSI Mid Layer Guide</title> + + <authorgroup> + <author> + <firstname>James</firstname> + <surname>Bottomley</surname> + <affiliation> + <address> + <email>[email protected]</email> + </address> + </affiliation> + </author> + + <author> + <firstname>Rob</firstname> + <surname>Landley</surname> + <affiliation> + <address> + <email>[email protected]</email> + </address> + </affiliation> + </author> + + </authorgroup> + + <copyright> + <year>2007</year> + <holder>Linux Foundation</holder> + </copyright> + + <legalnotice> + <para> + This documentation is free software; you can redistribute + it and/or modify it under the terms of the GNU General Public + License version 2. + </para> + + <para> + This program is distributed in the hope that it will be + useful, but WITHOUT ANY WARRANTY; without even the implied + warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + For more details see the file COPYING in the source + distribution of Linux. + </para> + </legalnotice> + </bookinfo> + + <toc></toc> + + <chapter id="intro"> + <title>Introduction</title> + <sect1 id="protocol_vs_bus"> + <title>Protocol vs bus</title> + <para> + Once upon a time, the Small Computer Systems Interface defined both + a parallel I/O bus and a data protocol to connect a wide variety of + peripherals (disk drives, tape drives, modems, printers, scanners, + optical drives, test equipment, and medical devices) to a host + computer. + </para> + <para> + Although the old parallel (fast/wide/ultra) SCSI bus has largely + fallen out of use, the SCSI command set is more widely used than ever + to communicate with devices over a number of different busses. + </para> + <para> + The <ulink url='http://www.t10.org/scsi-3.htm'>SCSI protocol</ulink> + is a big-endian peer-to-peer packet based protocol. SCSI commands + are 6, 10, 12, or 16 bytes long, often followed by an associated data + payload. + </para> + <para> + SCSI commands can be transported over just about any kind of bus, and + are the default protocol for storage devices attached to USB, SATA, + SAS, Fibre Channel, FireWire, and ATAPI devices. SCSI packets are + also commonly exchanged over Infiniband, + <ulink url='http://i2o.shadowconnect.com/faq.php'>I20</ulink>, TCP/IP + (<ulink url='http://en.wikipedia.org/wiki/ISCSI'>iSCSI</ulink>), even + <ulink url='http://cyberelk.net/tim/parport/parscsi.html'>Parallel + ports</ulink>. + </para> + </sect1> + <sect1 id="subsystem_design"> + <title>Design of the Linux SCSI subsystem</title> + <para> + The SCSI subsystem uses a three layer design, with upper, mid, and low + layers. Every operation involving the SCSI subsystem (such as reading + a sector from a disk) uses one driver at each of the 3 levels: one + upper layer driver, one lower layer driver, and the scsi midlayer. + </para> + <para> + The SCSI upper layer provides the interface between userspace and the + kernel, in the form of block and char device nodes for I/O and + ioctl(). The SCSI lower layer contains drivers for specific hardware + devices. + </para> + <para> + In between is the SCSI mid-layer, analogous to a network routing + layer such as the IPv4 stack. The SCSI mid-layer routes a packet + based data protocol between the upper layer's /dev nodes and the + corresponding devices in the lower layer. It manages command queues, + provides error handling and power management functions, and responds + to ioctl() requests. + </para> + </sect1> + </chapter> + + <chapter id="upper_layer"> + <title>SCSI upper layer</title> + <para> + The upper layer supports the user-kernel interface by providing + device nodes. + </para> + <sect1 id="sd"> + <title>sd (SCSI Disk)</title> + <para>sd (sd_mod.o)</para> +<!-- !Idrivers/scsi/sd.c --> + </sect1> + <sect1 id="sr"> + <title>sr (SCSI CD-ROM)</title> + <para>sr (sr_mod.o)</para> + </sect1> + <sect1 id="st"> + <title>st (SCSI Tape)</title> + <para>st (st.o)</para> + </sect1> + <sect1 id="sg"> + <title>sg (SCSI Generic)</title> + <para>sg (sg.o)</para> + </sect1> + <sect1 id="ch"> + <title>ch (SCSI Media Changer)</title> + <para>ch (ch.c)</para> + </sect1> + </chapter> + + <chapter id="mid_layer"> + <title>SCSI mid layer</title> + + <sect1 id="midlayer_implementation"> + <title>SCSI midlayer implementation</title> + <sect2 id="scsi_device.h"> + <title>include/scsi/scsi_device.h</title> + <para> + </para> +!Iinclude/scsi/scsi_device.h + </sect2> + + <sect2 id="scsi.c"> + <title>drivers/scsi/scsi.c</title> + <para>Main file for the scsi midlayer.</para> +!Edrivers/scsi/scsi.c + </sect2> + <sect2 id="scsicam.c"> + <title>drivers/scsi/scsicam.c</title> + <para> + <ulink url='http://www.t10.org/ftp/t10/drafts/cam/cam-r12b.pdf'>SCSI + Common Access Method</ulink> support functions, for use with + HDIO_GETGEO, etc. + </para> +!Edrivers/scsi/scsicam.c + </sect2> + <sect2 id="scsi_error.c"> + <title>drivers/scsi/scsi_error.c</title> + <para>Common SCSI error/timeout handling routines.</para> +!Edrivers/scsi/scsi_error.c + </sect2> + <sect2 id="scsi_devinfo.c"> + <title>drivers/scsi/scsi_devinfo.c</title> + <para> + Manage scsi_dev_info_list, which tracks blacklisted and whitelisted + devices. + </para> +!Idrivers/scsi/scsi_devinfo.c + </sect2> + <sect2 id="scsi_ioctl.c"> + <title>drivers/scsi/scsi_ioctl.c</title> + <para> + Handle ioctl() calls for scsi devices. + </para> +!Edrivers/scsi/scsi_ioctl.c + </sect2> + <sect2 id="scsi_lib.c"> + <title>drivers/scsi/scsi_lib.c</title> + <para> + SCSI queuing library. + </para> +!Edrivers/scsi/scsi_lib.c + </sect2> + <sect2 id="scsi_lib_dma.c"> + <title>drivers/scsi/scsi_lib_dma.c</title> + <para> + SCSI library functions depending on DMA + (map and unmap scatter-gather lists). + </para> +!Edrivers/scsi/scsi_lib_dma.c + </sect2> + <sect2 id="scsi_module.c"> + <title>drivers/scsi/scsi_module.c</title> + <para> + The file drivers/scsi/scsi_module.c contains legacy support for + old-style host templates. It should never be used by any new driver. + </para> + </sect2> + <sect2 id="scsi_proc.c"> + <title>drivers/scsi/scsi_proc.c</title> + <para> + The functions in this file provide an interface between + the PROC file system and the SCSI device drivers + It is mainly used for debugging, statistics and to pass + information directly to the lowlevel driver. + + I.E. plumbing to manage /proc/scsi/* + </para> +!Idrivers/scsi/scsi_proc.c + </sect2> + <sect2 id="scsi_netlink.c"> + <title>drivers/scsi/scsi_netlink.c</title> + <para> + Infrastructure to provide async events from transports to userspace + via netlink, using a single NETLINK_SCSITRANSPORT protocol for all + transports. + + See <ulink url='http://marc.info/?l=linux-scsi&m=115507374832500&w=2'>the + original patch submission</ulink> for more details. + </para> +!Idrivers/scsi/scsi_netlink.c + </sect2> + <sect2 id="scsi_scan.c"> + <title>drivers/scsi/scsi_scan.c</title> + <para> + Scan a host to determine which (if any) devices are attached. + + The general scanning/probing algorithm is as follows, exceptions are + made to it depending on device specific flags, compilation options, + and global variable (boot or module load time) settings. + + A specific LUN is scanned via an INQUIRY command; if the LUN has a + device attached, a scsi_device is allocated and setup for it. + + For every id of every channel on the given host, start by scanning + LUN 0. Skip hosts that don't respond at all to a scan of LUN 0. + Otherwise, if LUN 0 has a device attached, allocate and setup a + scsi_device for it. If target is SCSI-3 or up, issue a REPORT LUN, + and scan all of the LUNs returned by the REPORT LUN; else, + sequentially scan LUNs up until some maximum is reached, or a LUN is + seen that cannot have a device attached to it. + </para> +!Idrivers/scsi/scsi_scan.c + </sect2> + <sect2 id="scsi_sysctl.c"> + <title>drivers/scsi/scsi_sysctl.c</title> + <para> + Set up the sysctl entry: "/dev/scsi/logging_level" + (DEV_SCSI_LOGGING_LEVEL) which sets/returns scsi_logging_level. + </para> + </sect2> + <sect2 id="scsi_sysfs.c"> + <title>drivers/scsi/scsi_sysfs.c</title> + <para> + SCSI sysfs interface routines. + </para> +!Edrivers/scsi/scsi_sysfs.c + </sect2> + <sect2 id="hosts.c"> + <title>drivers/scsi/hosts.c</title> + <para> + mid to lowlevel SCSI driver interface + </para> +!Edrivers/scsi/hosts.c + </sect2> + <sect2 id="constants.c"> + <title>drivers/scsi/constants.c</title> + <para> + mid to lowlevel SCSI driver interface + </para> +!Edrivers/scsi/constants.c + </sect2> + </sect1> + + <sect1 id="Transport_classes"> + <title>Transport classes</title> + <para> + Transport classes are service libraries for drivers in the scsi + lower layer, which expose transport attributes in sysfs. + </para> + <sect2 id="Fibre_Channel_transport"> + <title>Fibre Channel transport</title> + <para> + The file drivers/scsi/scsi_transport_fc.c defines transport attributes + for Fibre Channel. + </para> +!Edrivers/scsi/scsi_transport_fc.c + </sect2> + <sect2 id="iSCSI_transport"> + <title>iSCSI transport class</title> + <para> + The file drivers/scsi/scsi_transport_iscsi.c defines transport + attributes for the iSCSI class, which sends SCSI packets over TCP/IP + connections. + </para> +!Edrivers/scsi/scsi_transport_iscsi.c + </sect2> + <sect2 id="SAS_transport"> + <title>Serial Attached SCSI (SAS) transport class</title> + <para> + The file drivers/scsi/scsi_transport_sas.c defines transport + attributes for Serial Attached SCSI, a variant of SATA aimed at + large high-end systems. + </para> + <para> + The SAS transport class contains common code to deal with SAS HBAs, + an aproximated representation of SAS topologies in the driver model, + and various sysfs attributes to expose these topologies and managment + interfaces to userspace. + </para> + <para> + In addition to the basic SCSI core objects this transport class + introduces two additional intermediate objects: The SAS PHY + as represented by struct sas_phy defines an "outgoing" PHY on + a SAS HBA or Expander, and the SAS remote PHY represented by + struct sas_rphy defines an "incoming" PHY on a SAS Expander or + end device. Note that this is purely a software concept, the + underlying hardware for a PHY and a remote PHY is the exactly + the same. + </para> + <para> + There is no concept of a SAS port in this code, users can see + what PHYs form a wide port based on the port_identifier attribute, + which is the same for all PHYs in a port. + </para> +!Edrivers/scsi/scsi_transport_sas.c + </sect2> + <sect2 id="SATA_transport"> + <title>SATA transport class</title> + <para> + The SATA transport is handled by libata, which has its own book of + documentation in this directory. + </para> + </sect2> + <sect2 id="SPI_transport"> + <title>Parallel SCSI (SPI) transport class</title> + <para> + The file drivers/scsi/scsi_transport_spi.c defines transport + attributes for traditional (fast/wide/ultra) SCSI busses. + </para> +!Edrivers/scsi/scsi_transport_spi.c + </sect2> + <sect2 id="SRP_transport"> + <title>SCSI RDMA (SRP) transport class</title> + <para> + The file drivers/scsi/scsi_transport_srp.c defines transport + attributes for SCSI over Remote Direct Memory Access. + </para> +!Edrivers/scsi/scsi_transport_srp.c + </sect2> + </sect1> + + </chapter> + + <chapter id="lower_layer"> + <title>SCSI lower layer</title> + <sect1 id="hba_drivers"> + <title>Host Bus Adapter transport types</title> + <para> + Many modern device controllers use the SCSI command set as a protocol to + communicate with their devices through many different types of physical + connections. + </para> + <para> + In SCSI language a bus capable of carrying SCSI commands is + called a "transport", and a controller connecting to such a bus is + called a "host bus adapter" (HBA). + </para> + <sect2 id="scsi_debug.c"> + <title>Debug transport</title> + <para> + The file drivers/scsi/scsi_debug.c simulates a host adapter with a + variable number of disks (or disk like devices) attached, sharing a + common amount of RAM. Does a lot of checking to make sure that we are + not getting blocks mixed up, and panics the kernel if anything out of + the ordinary is seen. + </para> + <para> + To be more realistic, the simulated devices have the transport + attributes of SAS disks. + </para> + <para> + For documentation see + <ulink url='http://www.torque.net/sg/sdebug26.html'>http://www.torque.net/sg/sdebug26.html</ulink> + </para> +<!-- !Edrivers/scsi/scsi_debug.c --> + </sect2> + <sect2 id="todo"> + <title>todo</title> + <para>Parallel (fast/wide/ultra) SCSI, USB, SATA, + SAS, Fibre Channel, FireWire, ATAPI devices, Infiniband, + I20, iSCSI, Parallel ports, netlink... + </para> + </sect2> + </sect1> + </chapter> +</book>
Documentation/DocBook/Makefile +1 -1
@@ -11,7 +11,7 @@ DOCBOOKS := wanbook.xml z8530book.xml mc procfs-guide.xml writing_usb_driver.xml \ kernel-api.xml filesystems.xml lsm.xml usb.xml \ gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \ - genericirq.xml s390-drivers.xml + genericirq.xml s390-drivers.xml scsi_midlayer.xml ### # The build process is as follows (targets):
Signature · 2 lines
"One of my most productive days was throwing away 1000 lines of code." - Ken Thompson.
Quoted 3 lines · On Fri, 26 Oct 2007 23:18:00 -0500 Rob Landley wrote:
From: Rob Landley <[email protected]>
Add
Documentation/DocBook/scsi_midlayer.tmpland add toMakefile.
I have comments for all 15 patches here.
a. You should cc: the maintainer who you want/expect to apply the
patches. Always. Andrew Morton is the only person who trolls for patches on a mailing list. :)
b. The function "Description:" section header is not strictly
required by scripts/kernel-doc. It will assume that the first text section after parameters is the Description:
section. FYI.
c. Extraneous whitespace. Git or quilt check for this.
I don't know about hg...
patch 2:
Warning: trailing whitespace in line 60 of drivers/scsi/scsicam.c
patch 6:
Warning: trailing whitespace in line 185 of drivers/scsi/scsi_ioctl.c
patch 15:
Warning: trailing whitespace in lines 8,43 of Documentation/DocBook/scsi_midlayer.tmpl
The docbook builds cleanly and all of my following comments are just for cleanups/fixes.
General: SCSI, not scsi (in text descriptions, sentences, etc.) General: IRQ, not irq (in text) General: LLD, not lld (in text) (or LLDD, not lldd)
Chap. 1:
Can't SCSI commands also be 32 bytes long?
Chap. 3: Mid-layer:
It would make more sense to me to put extra comments like
Main file for the scsi midlayer.
just after the source file name instead of after all of the documented interfaces in that file.
scsi_finish_command - needs a short description on the first kernel-doc line. scsi_track_queue_full - ditto
__scsi_device_lookup_by_target: fix text:
The only reason why drivers would want to use this is because they're need to access the device list in irq context.
s/would want to/should/
s/they're/they/
scsi_eh_finish_cmd:
thus we really
s/thus/Thus/
scsi_eh_get_sense:
proccessed (sp)
This has the unfortunate side effect that if a shost adapter does not automatically request sense information, that we end up shutting it down before we request it.
Ugh. Fix.
scsi_sense_desc_find:
short function description needs to be all on one line and no blank line before parameters.
scsi_get_sense_info_fld:
same comments as above.
scsi_init_devinfo:
Don't end kernel-doc with **/ (this is just a convention, not a syntax rule).
HTML output of the function description is there 2 times. I'll look into this problem.
scsi_mode_sense:
function short description must be on one line only (can be a long line
if needed)
Description text is repeated in html output; this is usually due to the function desc. being on multiple lines.
scsi_device_set_state:
short func desc on one line only.
scsi_internal_device_block:
short func desc on one line only.
scsi_kunmap_atomic_sg:
short func desc on one line only.
scsi_target_reap:
no blank line before parameter list
scsi_inq_str:
short func desc on one line only.
scsi_host_set_state:
short func desc on one line only.
scsi_host_lookup:
no blank line before parameter list
fc_host_post_event:
short func desc on one line only.
fc_host_post_vendor_event:
a fc_host
s/a/an/
fc_remove_host:
short func desc on one line only.
fc_remote_port_add:
short func desc on one line only.
fc_remote_port_delete:
short func desc on one line only.
fc_remote_port_rolechg:
short func desc on one line only.
iscsi_destroy_conn:
This can be called from a LLD or iscsi_transport.
s/a/an/
sas_remove_children:sas_remove_host:sas_phy_alloc:sas_phy_add:sas_phy_free:sas_phy_delete:scsi_is_sas_phy:sas_port_delete:scsi_is_sas_port:sas_rphy_add:sas_rphy_free:sas_rphy_delete:sas_rphy_remove:scsi_is_sas_rphy:sas_attach_transport:sas_release_transport:
s/--/-/ in first line of kernel-doc
sas_port_add:
no blank line before parameter list
srp_rport_add:
no blank line before parameter list
srp_rport_del:srp_remove_host:srp_attach_transport:srp_release_transport:
s/--/-/ in first line of kernel-doc
###
Thanks,
---
~Randy
Quoted 4 lines · Randy Dunlap
Quoted 2 lines · On Fri, 26 Oct 2007 23:18:00 -0500 Rob Landley wrote:
From: Rob Landley <[email protected]>
Quoted 8 lines
Quoted 1 line
Add
Documentation/DocBook/scsi_midlayer.tmpland add toMakefile.I have comments for all 15 patches here.
a. You should cc: the maintainer who you want/expect to apply the
patches. Always. Andrew Morton is the only person who trolls for patches on a mailing list. :)
Realistically too, for this first batch that covers mostly the mid-layer and the transport classes, a single patch like you originally submitted was just fine. One patch per file isn't. Patches should be split across functional areas (in this case the function is simply adding the SCSI mid layer to the docbook build, so they can all go together).
Quoted 7 lines
b. The function "Description:" section header is not strictly
required byscripts/kernel-doc. It will assume that the first text section after parameters is the Description:
section. FYI.c. Extraneous whitespace. Git or quilt check for this.
I don't know about hg...
Actually, the checkpatch.pl script in the scripts directory of the kernel is very good for this (I ran it on the original monolithic patch):
jejb@mulgrave> ./scripts/checkpatch.pl ~/tmp.mail
ERROR: trailing whitespace
#1065: FILE: drivers/scsi/scsi_ioctl.c:185:
+ * a pointer to a &struct scsi_device. $
ERROR: trailing whitespace
#1670: FILE: drivers/scsi/scsicam.c:60:
+ * Description : determine the BIOS mapping/geometry used for a drive in a $
total: 2 errors, 0 warnings, 1502 lines checked
Your patch has style problems, please review. If any of these errors are false positives report them to the maintainer, see CHECKPATCH in MAINTAINERS.
In addition, there seem to be a few functions that you added kerneldoc for which don't show up in the doc output. The one that caught my eye was scsi_cmd_get_serial(), but I think there are others.
James
Quoted 12 lines · James Bottomley
Quoted 10 lines · Randy Dunlap
Quoted 3 lines · On Fri, 26 Oct 2007 23:18:00 -0500 Rob Landley wrote:
From: Rob Landley <[email protected]>
Add
Documentation/DocBook/scsi_midlayer.tmpland add toMakefile.I have comments for all 15 patches here.
a. You should cc: the maintainer who you want/expect to apply the
patches. Always. Andrew Morton is the only person who trolls for patches on a mailing list. :)
Quoted 5 lines
Realistically too, for this first batch that covers mostly the mid-layer and the transport classes, a single patch like you originally submitted was just fine. One patch per file isn't. Patches should be split across functional areas (in this case the function is simply adding the SCSI mid layer to the docbook build, so they can all go together).
Ooh, that makes things much easier on me. Thanks. :)
Quoted 11 lines
Quoted 7 lines
b. The function "Description:" section header is not strictly
required byscripts/kernel-doc. It will assume that the first text section after parameters is the Description:
section. FYI.c. Extraneous whitespace. Git or quilt check for this.
I don't know about hg...Actually, the checkpatch.pl script in the scripts directory of the kernel is very good for this (I ran it on the original monolithic patch):
Ok. I'll add that to my ~/cannon.sh to put a patch in cannonical format.
Quoted 3 lines
In addition, there seem to be a few functions that you added kerneldoc for which don't show up in the doc output. The one that caught my eye was
scsi_cmd_get_serial(), but I think there are others.
I'm replying to Randy's message in another window as I deal with the issues he raised, but I'll cut and paste that chunk over here:
These comments could use a lot more work in general. Several exported functions aren't commented at all, and several files have both internal functions and external functions with kerneldoc comments (which I'm currently grabbing only one or the other of, because the build has !I and !E which grab one of the other, and both complain and insert junk into the output if the file hasn't got any of the type it's looking for).
Ideally I'd like to grab them all in one pass and annotate each function name with the export type (if any). Not just "is it exported" but is it EXPORT_SYMBOL or EXPORT_SYMBOL_GPL or whatever those EXPORT_PER_CPU_SYMBOL things are I haven't had time to look into yet. But this requires a change to the kernel build infrastructure. (I hope it can be done in docproc.c, I really don't like trying to modify other people's perl code. Anyway, todo item. Probably a new include type !B for both. Possibly I could currently combine !I and !D now, but then I wouldn't get the annotations about export type...)
Quoted 1 line
James
Rob
Signature · 2 lines
"One of my most productive days was throwing away 1000 lines of code." - Ken Thompson.
Quoted 10 lines · Randy Dunlap
Quoted 3 lines · On Fri, 26 Oct 2007 23:18:00 -0500 Rob Landley wrote:
From: Rob Landley <[email protected]>
Add
Documentation/DocBook/scsi_midlayer.tmpland add toMakefile.I have comments for all 15 patches here.
a. You should cc: the maintainer who you want/expect to apply the
patches. Always. Andrew Morton is the only person who trolls for patches on a mailing list. :)
I CC: Andrew when I send to linux-kernel. I was under the impression linux-scsi was a lower traffic list.
Quoted 4 lines
b. The function "Description:" section header is not strictly
required byscripts/kernel-doc. It will assume that the first text section after parameters is the Description:
section. FYI.
Ok.
Quoted 2 lines
c. Extraneous whitespace. Git or quilt check for this.
I don't know about hg...
There might be a flag, but I haven't checked any of this in, just used it to diff against a current base.
Quoted 9 lines
patch 2:
Warning: trailing whitespace in line 60 ofdrivers/scsi/scsicam.cpatch 6:
Warning: trailing whitespace in line 185 ofdrivers/scsi/scsi_ioctl.cpatch 15:
Warning: trailing whitespace in lines 8,43 ofDocumentation/DocBook/scsi_midlayer.tmpl
Got it.
Quoted 7 lines
The docbook builds cleanly and all of my following comments are just for cleanups/fixes.
General: SCSI, not scsi (in text descriptions, sentences, etc.) General: IRQ, not irq (in text) General: LLD, not lld (in text) (or LLDD, not lldd)
Changed 3 or 4 instances of lowercase scsi to SCSI in the docbook. Didn't find an irq or lld in there.
Keep in mind I wrote less than half of the kerneldoc comments in these files. "They're" and failing to capitalize the first word of each sentence were common patterns I tried to fix up where I could, but I missed a bunch.
These comments need a lot more work in general, and I just moved the explanation of that statement to the response to James Bottomley's email.
Quoted 2 lines
Chap. 1:
Can't SCSI commands also be 32 bytes long?
I have no idea, ask the first paragraph of:
http://sg.torque.net/sg/p/sg_v3_ho.html#what
I was initially trying to integrate that and the 2.4 SCSI howto into this document, but I A) just didn't have time this week, B) have idea which parts of that are out of date. (And C) still don't understand large chunks of it, although that's mostly just a restatement of A.)
If you can confirm "yes they can be 32 bytes long" I can add it...
Quoted 6 lines
Chap. 3: Mid-layer:
It would make more sense to me to put extra comments like
Main file for the scsi midlayer.
just after the source file name instead of after all of the documented interfaces in that file.
You mean like:
<sect2 id="scsi.c">
<title>drivers/scsi/scsi.c</title> <para>Main file for the SCSI midlayer.</para>
Which is what the tmpl file says now? That's the only instance of it in the file that I can find. I don't understand what you're asking for.
Quoted 2 lines
scsi_finish_command- needs a short description on the first kernel-doc line.scsi_track_queue_full- ditto
Ok, took a stab at it.
Quoted 6 lines
__scsi_device_lookup_by_target: fix text:
The only reason why drivers would want to use this is because they're need to access the device list in irq context.s/would want to/should/
s/they're/they/
Got it.
Quoted 5 lines
scsi_eh_finish_cmd:thus we really
s/thus/Thus/
Ah, missed one. Got it.
Quoted 2 lines
scsi_eh_get_sense:
proccessed (sp)
Fixed.
Quoted 5 lines
This has the unfortunate side effect that if a shost adapter does not automatically request sense information, that we end up shutting it down before we request it.
Ugh. Fix.
Done.
Quoted 3 lines
scsi_sense_desc_find:
short function description needs to be all on one line and no blank line before parameters.
Yup. Got it.
Quoted 2 lines
scsi_get_sense_info_fld:
same comments as above.
And again, fixed.
Quoted 3 lines
scsi_init_devinfo:
Don't end kernel-doc with **/ (this is just a convention, not a syntax rule).
I don't, but this file has a lot of 'em, doesn't it? Removed...
Quoted 2 lines
HTML output of the function description is there 2 times. I'll look into this problem.
Ok...
Quoted 6 lines
scsi_mode_sense:
function short description must be on one line only (can be a long line
if needed)
Description text is repeated in html output; this is usually due to the function desc. being on multiple lines.
Quoted 6 lines
scsi_device_set_state:
short func desc on one line only.
scsi_internal_device_block:
short func desc on one line only.
Got 'em.
Quoted 8 lines
scsi_kunmap_atomic_sg:
short func desc on one line only.
scsi_target_reap:
no blank line before parameter list
scsi_inq_str:
short func desc on one line only.
Got 'em.
Quoted 7 lines
scsi_host_set_state:
short func desc on one line only.
scsi_host_lookup:
no blank line before parameter list
Quoted 7 lines
fc_host_post_event:
short func desc on one line only.
fc_host_post_vendor_event:
afc_hosts/a/an/
ok
Quoted 9 lines
fc_remove_host:
short func desc on one line only.
fc_remote_port_add:
short func desc on one line only.
fc_remote_port_delete:
short func desc on one line only.
Quoted 7 lines
fc_remote_port_rolechg:
short func desc on one line only.
iscsi_destroy_conn:
This can be called from a LLD oriscsi_transport.s/a/an/
Got it.
Quoted 22 lines
sas_remove_children:sas_remove_host:sas_phy_alloc:sas_phy_add:sas_phy_free:sas_phy_delete:scsi_is_sas_phy:sas_port_delete:scsi_is_sas_port:sas_rphy_add:sas_rphy_free:sas_rphy_delete:sas_rphy_remove:scsi_is_sas_rphy:sas_attach_transport:sas_release_transport:
s/--/-/ in first line of kernel-doc
sas_port_add:
no blank line before parameter list
Quoted 8 lines
srp_rport_add:
no blank line before parameter list
srp_rport_del:srp_remove_host:srp_attach_transport:srp_release_transport:
s/--/-/ in first line of kernel-doc
Got it.
Quoted 4 lines
###
Thanks,
---
~Randy
Updated drivers/scsi/* patch attached.
Rob
Signature · 2 lines
"One of my most productive days was throwing away 1000 lines of code." - Ken Thompson.
drivers/scsi/constants.c +0 -1
@@ -362,7 +362,6 @@ EXPORT_SYMBOL(scsi_print_command);EXPORT_SYMBOL (scsi_print_command);/** -* * scsi_print_status - print scsi status description * @scsi_status: scsi status value *
drivers/scsi/hosts.c +1 -3
@@ -54,8 +54,7 @@ static struct class shost_class = { };/** -* scsi_host_set_state - Take the given host through the host -* state model. +* scsi_host_set_state - Take the given host through the host state model. * @shost: scsi host to change the state of. * @state: state to change to. *
@@ -425,7 +424,6 @@ EXPORT_SYMBOL(scsi_unregister);/** * scsi_host_lookup - get a reference to a Scsi_Host by host no -* * @hostnum: host number to locate * * Return value:
drivers/scsi/scsi.c +103 -94
362 lines not on this page · raw message
drivers/scsi/scsi_devinfo.c +16 -20
@@ -276,11 +276,12 @@ static void scsi_strcpy_devinfo(char *na }/** -* scsi_dev_info_list_add: add one dev_info list entry. +* scsi_dev_info_list_add - add one dev_info list entry. +* @compatible: if true, null terminate short strings. Otherwise space pad. * @vendor: vendor string * @model: model (product) string * @strflags: integer string -* @flag: if strflags NULL, use this flag value +* @flags: if strflags NULL, use this flag value * * Description: * Create and add one dev_info entry for @vendor, @model, @strflags or
@@ -322,8 +323,7 @@ static int scsi_dev_info_list_add(int co }/** -* scsi_dev_info_list_add_str: parse dev_list and add to the -* scsi_dev_info_list. +* scsi_dev_info_list_add_str - parse dev_list and add to the scsi_dev_info_list. * @dev_list: string of device flags to add * * Description:
@@ -374,15 +374,15 @@ static int scsi_dev_info_list_add_str(ch }/** -* get_device_flags - get device specific flags from the dynamic device -* list. Called during scan time. +* get_device_flags - get device specific flags from the dynamic device list. +* @sdev: &scsi_device to get flags for * @vendor: vendor name * @model: model name * * Description: * Search the scsi_dev_info_list for an entry matching @vendor and * @model, if found, return the matching flags value, else return -* the host or global default settings. +* the host or global default settings. Called during scan time. **/ int scsi_get_device_flags(struct scsi_device *sdev, const unsigned char *vendor,
@@ -483,13 +483,11 @@ stop_output: }/* -* proc_scsi_dev_info_write: allow additions to the scsi_dev_info_list via -* /proc. -* -* Use: echo "vendor:model:flag" > /proc/scsi/device_info -* -* To add a black/white list entry for vendor and model with an integer -* value of flag to the scsi device info list. +* proc_scsi_dev_info_write - allow additions to scsi_dev_info_list via /proc. +* +* Description: Adds a black/white list entry for vendor and model with an +* integer value of flag to the scsi device info list. +* To use, echo "vendor:model:flag" > /proc/scsi/device_info */ static int proc_scsi_devinfo_write (struct file *file,const char __user *buf,unsigned long length,void *data)
@@ -532,8 +530,7 @@ MODULE_PARM_DESC(default_dev_flags, "scsi default device flag integer value");/** -* scsi_dev_info_list_delete: called from scsi.c:exit_scsi to remove -* the scsi_dev_info_list. +* scsi_dev_info_list_delete - called from scsi.c:exit_scsi to remove the scsi_dev_info_list. **/ void scsi_exit_devinfo (void ) {
@@ -552,13 +549,12 @@ void scsi_exit_devinfo(void) }/** -* scsi_dev_list_init: set up the dynamic device list. -* @dev_list: string of device flags to add +* scsi_dev_list_init - set up the dynamic device list. * * Description: -* Add command line @dev_list entries, then add +* Add command line entries from scsi_dev_flags, then add * scsi_static_device_list entries to the scsi device info list. -**/ +*/ int __init scsi_init_devinfo (void ) {#ifdef CONFIG_SCSI_PROC_FS
drivers/scsi/scsi_error.c +23 -23
123 lines not on this page · raw message
drivers/scsi/scsi_ioctl.c +16 -8
@@ -174,10 +174,15 @@ static int scsi_ioctl_get_pci(struct scs } -/* -* the scsi_ioctl() function differs from most ioctls in that it does -* not take a major/minor number as the dev field. Rather, it takes -* a pointer to a scsi_devices[] element, a structure. +/** +* scsi_ioctl - Dispatch ioctl to scsi device +* @sdev: scsi device receiving ioctl +* @cmd: which ioctl is it +* @arg: data associated with ioctl +* +* Description: The scsi_ioctl() function differs from most ioctls in that it +* does not take a major/minor number as the dev field. Rather, it takes +* a pointer to a &struct scsi_device. */ int scsi_ioctl (struct scsi_device *sdev,int cmd,void __user *arg) {
@@ -264,9 +269,12 @@ int scsi_ioctl(struct scsi_device *sdev, }EXPORT_SYMBOL (scsi_ioctl); -/* -* the scsi_nonblock_ioctl() function is designed for ioctls which may -* be executed even if the device is in recovery. +/** +* scsi_nonblock_ioctl() - Handle SG_SCSI_RESET +* @sdev: scsi device receiving ioctl +* @cmd: Must be SC_SCSI_RESET +* @arg: pointer to int containing SG_SCSI_RESET_{DEVICE,BUS,HOST} +* @filp: either NULL or a &struct file which must have the O_NONBLOCK flag. */ int scsi_nonblockable_ioctl (struct scsi_device *sdev,int cmd,void __user *arg,struct file *filp)
@@ -276,7 +284,7 @@ int scsi_nonblockable_ioctl(struct scsi_/* The first set of iocts may be executed even if we're doing * error processing, as long as the device was opened * non-blocking */ -if (filp && filp->f_flags &O_NONBLOCK ) { +if (filp && (filp->f_flags &O_NONBLOCK )) {if (scsi_host_in_recovery (sdev->host))return -ENODEV ; }else if (!scsi_block_when_processing_errors (sdev))
drivers/scsi/scsi_lib.c +20 -22
141 lines not on this page · raw message
drivers/scsi/scsi_netlink.c +7 -12
@@ -32,11 +32,12 @@ EXPORT_SYMBOL_GPL(scsi_nl_sock);/** -* scsi_nl_rcv_msg - -* Receive message handler. Extracts message from a receive buffer. +* scsi_nl_rcv_msg - Receive message handler. +* @skb: socket receive buffer +* +* Description: Extracts message from a receive buffer. * Validates message header and calls appropriate transport message handler * -* @skb: socket receive buffer * **/ static void
@@ -99,9 +100,7 @@ next_msg:/** -* scsi_nl_rcv_event - -* Event handler for a netlink socket. -* +* scsi_nl_rcv_event - Event handler for a netlink socket. * @this: event notifier block * @event: event type * @ptr: event payload
@@ -129,9 +128,7 @@ static struct notifier_block scsi_netlin/** -* scsi_netlink_init - -* Called by SCSI subsystem to intialize the SCSI transport netlink -* interface +* scsi_netlink_init - Called by SCSI subsystem to intialize the SCSI transport netlink interface * **/ void
@@ -160,9 +157,7 @@ scsi_netlink_init(void)/** -* scsi_netlink_exit - -* Called by SCSI subsystem to disable the SCSI transport netlink -* interface +* scsi_netlink_exit - Called by SCSI subsystem to disable the SCSI transport netlink interface * **/ void
drivers/scsi/scsi_proc.c +108 -2
197 lines not on this page · raw message
drivers/scsi/scsi_scan.c +21 -13
@@ -221,6 +221,9 @@ static void scsi_unlock_floptical(struct/** * scsi_alloc_sdev - allocate and setup a scsi_Device +* @starget: which target to allocate a &scsi_device for +* @lun: which lun +* @hostdata: usually NULL and set by ->slave_alloc instead * * Description: * Allocate, initialize for io, and return a pointer to a scsi_Device.
@@ -469,7 +472,6 @@ static void scsi_target_reap_usercontext/** * scsi_target_reap - check to see if target is in use and destroy if not -* * @starget: target to be checked * * This is used after removing a LUN or doing a last put of the target
@@ -925,8 +927,7 @@ static inline void scsi_destroy_sdev(str#ifdef CONFIG_SCSI_LOGGING /** -* scsi_inq_str - print INQUIRY data from min to max index, -* strip trailing whitespace +* scsi_inq_str - print INQUIRY data from min to max index, strip trailing whitespace * @buf: Output buffer with at least end-first+1 bytes of space * @inq: Inquiry buffer (input) * @first: Offset of string into inq
@@ -954,9 +955,10 @@ static unsigned char *scsi_inq_str(unsig* scsi_probe_and_add_lun - probe a LUN, if a LUN is found add it * @starget: pointer to target device structure * @lun: LUN of target device -* @sdevscan: probe the LUN corresponding to this scsi_device -* @sdevnew: store the value of any new scsi_device allocated * @bflagsp: store bflags here if not NULL +* @sdevp: probe the LUN corresponding to this scsi_device +* @rescan: if nonzero skip some code only needed on first scan +* @hostdata: passed to scsi_alloc_sdev() * * Description: * Call scsi_probe_lun, if a LUN with an attached device is found,
@@ -1107,6 +1109,8 @@ static int scsi_probe_and_add_lun(struct* scsi_sequential_lun_scan - sequentially scan a SCSI target * @starget: pointer to target structure to scan * @bflags: black/white list flag for LUN 0 +* @scsi_level: Which version of the standard does this device adhere to +* @rescan: passed to scsi_probe_add_lun() * * Description: * Generally, scan from LUN 1 (LUN 0 is assumed to already have been
@@ -1217,7 +1221,7 @@ EXPORT_SYMBOL(scsilun_to_int);/** * int_to_scsilun: reverts an int into a scsi_lun -* @int: integer to be reverted +* @lun: integer to be reverted * @scsilun: struct scsi_lun to be set. * * Description:
@@ -1249,18 +1253,22 @@ EXPORT_SYMBOL(int_to_scsilun);/** * scsi_report_lun_scan - Scan using SCSI REPORT LUN results -* @sdevscan: scan the host, channel, and id of this scsi_device +* @starget: which target +* @bflags: Zero or a mix of BLIST_NOLUN, BLIST_REPORTLUN2, or BLIST_NOREPORTLUN +* @rescan: nonzero if we can skip code only needed on first scan * * Description: -* If @sdevscan is for a SCSI-3 or up device, send a REPORT LUN -* command, and scan the resulting list of LUNs by calling -* scsi_probe_and_add_lun. -* -* Modifies sdevscan->lun. +* Fast scanning for modern (SCSI-3) devices by sending a REPORT LUN command. +* Scan the resulting list of LUNs by calling scsi_probe_and_add_lun. +* +* If BLINK_REPORTLUN2 is set, scan a target that supports more than 8 +* LUNs even if it's older than SCSI-3. +* If BLIST_NOREPORTLUN is set, return 1 always. +* If BLIST_NOLUN is set, return 0 always. * * Return: * 0: scan completed (or no memory, so further scanning is futile) -* 1: no report lun scan, or not configured +* 1: could not scan with REPORT LUN **/ static int scsi_report_lun_scan (struct scsi_target *starget,int bflags,int rescan)
drivers/scsi/scsi_transport_fc.c +47 -57
311 lines not on this page · raw message
drivers/scsi/scsi_transport_iscsi.c +9 -8
@@ -328,9 +328,10 @@ EXPORT_SYMBOL_GPL(iscsi_add_session);* iscsi_create_session - create iscsi class session * @shost: scsi host * @transport: iscsi transport +* @target_id: which target * * This can be called from a LLD or iscsi_transport. -**/ +*/ struct iscsi_cls_session * iscsi_create_session(struct Scsi_Host *shost, struct iscsi_transport *transport,
@@ -382,7 +383,7 @@ EXPORT_SYMBOL_GPL(iscsi_free_session);* * Can be called by a LLD or iscsi_transport. There must not be * any running connections. -**/ +*/ int iscsi_destroy_session (struct iscsi_cls_session *session) {iscsi_remove_session (session);
@@ -418,7 +419,7 @@ static int iscsi_is_conn_dev(const struc* for software iscsi we could be trying to preallocate a connection struct * in which case there could be two connection structs and cid would be * non-zero. -**/ +*/ struct iscsi_cls_conn *iscsi_create_conn (struct iscsi_cls_session *session,uint32_t cid) {
@@ -465,10 +466,10 @@ EXPORT_SYMBOL_GPL(iscsi_create_conn);/** * iscsi_destroy_conn - destroy iscsi class connection -* @session: iscsi cls session +* @conn: iscsi cls session * -* This can be called from a LLD or iscsi_transport. -**/ +* This can be called from an LLD or iscsi_transport. +*/ int iscsi_destroy_conn (struct iscsi_cls_conn *conn) {transport_unregister_device (&conn->dev);
@@ -690,7 +691,7 @@ iscsi_if_get_stats(struct iscsi_transpor* * This is called by HW iscsi LLDs to notify userpsace that its HW has * removed a session. -**/ +*/ int iscsi_if_destroy_session_done (struct iscsi_cls_conn *conn) {struct iscsi_internal *priv;
@@ -751,7 +752,7 @@ EXPORT_SYMBOL_GPL(iscsi_if_destroy_sessi* * This is called by HW iscsi LLDs to notify userpsace that its HW has * created a session or a existing session is back in the logged in state. -**/ +*/ int iscsi_if_create_session_done (struct iscsi_cls_conn *conn) {struct iscsi_internal *priv;
drivers/scsi/scsi_transport_sas.c +21 -19
@@ -323,7 +323,7 @@ static int do_sas_phy_delete(struct devi }/** -* sas_remove_children -- tear down a devices SAS data structures +* sas_remove_children - tear down a devices SAS data structures * @dev: device belonging to the sas object * * Removes all SAS PHYs and remote PHYs for a given object
@@ -336,7 +336,7 @@ EXPORT_SYMBOL(sas_remove_children);EXPORT_SYMBOL (sas_remove_children);/** -* sas_remove_host -- tear down a Scsi_Host's SAS data structures +* sas_remove_host - tear down a Scsi_Host's SAS data structures * @shost: Scsi Host that is torn down * * Removes all SAS PHYs and remote PHYs for a given Scsi_Host.
@@ -577,7 +577,7 @@ static void sas_phy_release(struct devic }/** -* sas_phy_alloc -- allocates and initialize a SAS PHY structure +* sas_phy_alloc - allocates and initialize a SAS PHY structure * @parent: Parent device * @number: Phy index *
@@ -618,7 +618,7 @@ EXPORT_SYMBOL(sas_phy_alloc);EXPORT_SYMBOL (sas_phy_alloc);/** -* sas_phy_add -- add a SAS PHY to the device hierarchy +* sas_phy_add - add a SAS PHY to the device hierarchy * @phy: The PHY to be added * * Publishes a SAS PHY to the rest of the system.
@@ -638,7 +638,7 @@ EXPORT_SYMBOL(sas_phy_add);EXPORT_SYMBOL (sas_phy_add);/** -* sas_phy_free -- free a SAS PHY +* sas_phy_free - free a SAS PHY * @phy: SAS PHY to free * * Frees the specified SAS PHY.
@@ -655,7 +655,7 @@ EXPORT_SYMBOL(sas_phy_free);EXPORT_SYMBOL (sas_phy_free);/** -* sas_phy_delete -- remove SAS PHY +* sas_phy_delete - remove SAS PHY * @phy: SAS PHY to remove * * Removes the specified SAS PHY. If the SAS PHY has an
@@ -677,7 +677,7 @@ EXPORT_SYMBOL(sas_phy_delete);EXPORT_SYMBOL (sas_phy_delete);/** -* scsi_is_sas_phy -- check if a struct device represents a SAS PHY +* scsi_is_sas_phy - check if a struct device represents a SAS PHY * @dev: device to check * * Returns:
@@ -843,7 +843,6 @@ EXPORT_SYMBOL(sas_port_alloc_num);/** * sas_port_add - add a SAS port to the device hierarchy -* * @port: port to be added * * publishes a port to the rest of the system
@@ -868,7 +867,7 @@ EXPORT_SYMBOL(sas_port_add);EXPORT_SYMBOL (sas_port_add);/** -* sas_port_free -- free a SAS PORT +* sas_port_free - free a SAS PORT * @port: SAS PORT to free * * Frees the specified SAS PORT.
@@ -885,7 +884,7 @@ EXPORT_SYMBOL(sas_port_free);EXPORT_SYMBOL (sas_port_free);/** -* sas_port_delete -- remove SAS PORT +* sas_port_delete - remove SAS PORT * @port: SAS PORT to remove * * Removes the specified SAS PORT. If the SAS PORT has an
@@ -924,7 +923,7 @@ EXPORT_SYMBOL(sas_port_delete);EXPORT_SYMBOL (sas_port_delete);/** -* scsi_is_sas_port -- check if a struct device represents a SAS port +* scsi_is_sas_port - check if a struct device represents a SAS port * @dev: device to check * * Returns:
@@ -1309,6 +1308,7 @@ static void sas_rphy_initialize(struct s/** * sas_end_device_alloc - allocate an rphy for an end device +* @parent: which port * * Allocates an SAS remote PHY structure, connected to @parent. *
@@ -1345,6 +1345,8 @@ EXPORT_SYMBOL(sas_end_device_alloc);/** * sas_expander_alloc - allocate an rphy for an end device +* @parent: which port +* @type: SAS_EDGE_EXPANDER_DEVICE or SAS_FANOUT_EXPANDER_DEVICE * * Allocates an SAS remote PHY structure, connected to @parent. *
@@ -1383,7 +1385,7 @@ EXPORT_SYMBOL(sas_expander_alloc);EXPORT_SYMBOL (sas_expander_alloc);/** -* sas_rphy_add -- add a SAS remote PHY to the device hierarchy +* sas_rphy_add - add a SAS remote PHY to the device hierarchy * @rphy: The remote PHY to be added * * Publishes a SAS remote PHY to the rest of the system.
@@ -1430,8 +1432,8 @@ EXPORT_SYMBOL(sas_rphy_add);EXPORT_SYMBOL (sas_rphy_add);/** -* sas_rphy_free -- free a SAS remote PHY -* @rphy SAS remote PHY to free +* sas_rphy_free - free a SAS remote PHY +* @rphy: SAS remote PHY to free * * Frees the specified SAS remote PHY. *
@@ -1459,7 +1461,7 @@ EXPORT_SYMBOL(sas_rphy_free);EXPORT_SYMBOL (sas_rphy_free);/** -* sas_rphy_delete -- remove and free SAS remote PHY +* sas_rphy_delete - remove and free SAS remote PHY * @rphy: SAS remote PHY to remove and free * * Removes the specified SAS remote PHY and frees it.
@@ -1473,7 +1475,7 @@ EXPORT_SYMBOL(sas_rphy_delete);EXPORT_SYMBOL (sas_rphy_delete);/** -* sas_rphy_remove -- remove SAS remote PHY +* sas_rphy_remove - remove SAS remote PHY * @rphy: SAS remote phy to remove * * Removes the specified SAS remote PHY.
@@ -1504,7 +1506,7 @@ EXPORT_SYMBOL(sas_rphy_remove);EXPORT_SYMBOL (sas_rphy_remove);/** -* scsi_is_sas_rphy -- check if a struct device represents a SAS remote PHY +* scsi_is_sas_rphy - check if a struct device represents a SAS remote PHY * @dev: device to check * * Returns:
@@ -1604,7 +1606,7 @@ static int sas_user_scan(struct Scsi_Hos SETUP_TEMPLATE(expander_attrs, expander_##field, S_IRUGO, 1)/** -* sas_attach_transport -- instantiate SAS transport template +* sas_attach_transport - instantiate SAS transport template * @ft: SAS transport class function template */ struct scsi_transport_template *
@@ -1715,7 +1717,7 @@ EXPORT_SYMBOL(sas_attach_transport);EXPORT_SYMBOL (sas_attach_transport);/** -* sas_release_transport -- release SAS transport template instance +* sas_release_transport - release SAS transport template instance * @t: transport template instance */ void sas_release_transport (struct scsi_transport_template *t)
drivers/scsi/scsi_transport_srp.c +5 -5
@@ -242,8 +242,8 @@ EXPORT_SYMBOL_GPL(srp_rport_add);EXPORT_SYMBOL_GPL (srp_rport_add);/** -* srp_rport_del -- remove a SRP remote port -* @port: SRP remote port to remove +* srp_rport_del - remove a SRP remote port +* @rport: SRP remote port to remove * * Removes the specified SRP remote port. */
@@ -270,7 +270,7 @@ static int do_srp_rport_del(struct devic }/** -* srp_remove_host -- tear down a Scsi_Host's SRP data structures +* srp_remove_host - tear down a Scsi_Host's SRP data structures * @shost: Scsi Host that is torn down * * Removes all SRP remote ports for a given Scsi_Host.
@@ -296,7 +296,7 @@ static int srp_it_nexus_response(struct }/** -* srp_attach_transport -- instantiate SRP transport template +* srp_attach_transport - instantiate SRP transport template * @ft: SRP transport class function template */ struct scsi_transport_template *
@@ -336,7 +336,7 @@ EXPORT_SYMBOL_GPL(srp_attach_transport);EXPORT_SYMBOL_GPL (srp_attach_transport);/** -* srp_release_transport -- release SRP transport template instance +* srp_release_transport - release SRP transport template instance * @t: transport template instance */ void srp_release_transport (struct scsi_transport_template *t)
drivers/scsi/scsicam.c +26 -13
@@ -24,6 +24,14 @@ static int setsize(unsigned long capacitstatic int setsize (unsigned long capacity,unsigned int *cyls,unsigned int *hds,unsigned int *secs); +/** +* scsi_bios_ptable - Read PC partition table out of first sector of device. +* @dev: from this device +* +* Description: Reads the first sector from the device and returns %0x42 bytes +* starting at offset %0x1be. +* Returns: partition table in kmalloc(GFP_KERNEL) memory, or NULL on error. +*/ unsigned char *scsi_bios_ptable (struct block_device *dev) {unsigned char *res =kmalloc (66 ,GFP_KERNEL );
@@ -43,15 +51,17 @@ unsigned char *scsi_bios_ptable(struct b }EXPORT_SYMBOL (scsi_bios_ptable); -/* -* Function : int scsicam_bios_param (struct block_device *bdev, ector_t capacity, int *ip) -* -* Purpose : to determine the BIOS mapping used for a drive in a +/** +* scsicam_bios_param - Determine geometry of a disk in cylinders/heads/sectors. +* @bdev: which device +* @capacity: size of the disk in sectors +* @ip: return value: ip[0]=heads, ip[1]=sectors, ip[2]=cylinders +* +* Description : determine the BIOS mapping/geometry used for a drive in a * SCSI-CAM system, storing the results in ip as required * by the HDIO_GETGEO ioctl(). * * Returns : -1 on failure, 0 on success. -* */ int scsicam_bios_param (struct block_device *bdev,sector_t capacity,int *ip)
@@ -98,15 +108,18 @@ int scsicam_bios_param(struct block_devi }EXPORT_SYMBOL (scsicam_bios_param); -/* -* Function : static int scsi_partsize(unsigned char *buf, unsigned long -* capacity,unsigned int *cyls, unsigned int *hds, unsigned int *secs); -* -* Purpose : to determine the BIOS mapping used to create the partition +/** +* scsi_partsize - Parse cylinders/heads/sectors from PC partition table +* @buf: partition table, see scsi_bios_ptable() +* @capacity: size of the disk in sectors +* @cyls: put cylinders here +* @hds: put heads here +* @secs: put sectors here +* +* Description: determine the BIOS mapping/geometry used to create the partition * table, storing the results in *cyls, *hds, and *secs * -* Returns : -1 on failure, 0 on success. -* +* Returns: -1 on failure, 0 on success. */ int scsi_partsize(unsigned char *buf, unsigned long capacity,
@@ -194,7 +207,7 @@ EXPORT_SYMBOL(scsi_partsize);* * WORKING X3T9.2 * DRAFT 792D -* +* see http://www.t10.org/ftp/t10/drafts/cam/cam-r12b.pdf * * Revision 6 * 10-MAR-94
James Bottomley
maintainerQuoted 1 line · Rob Landley
Updated
drivers/scsi/*patch attached.
This looks good; could you redo it, adding the missing scsi docbook tmpl file and add a change log and signed off by in the manner listed in Documentation/SubmittingPatches and it can go in.
Thanks,
James
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
James Bottomley
maintainerRe: [PATCH] Add Documentation/DocBook/scsi_midlayer.tmpl and update kerneldoc comments and Makefile.
Quoted 17 lines · Randy Dunlap
Quoted 5 lines · On Sat, 3 Nov 2007 13:30:39 -0500 Rob Landley wrote:
From: Rob Landley <[email protected]>
Add
Documentation/DocBook/scsi_midlayer.tmpl, add toMakefile, and update lots of kerneldoc comments indrivers/scsi/*.Quoted 8 lines
Updated with comments from Stefan Richter, Stephen M. Cameron,
James Bottomley and Randy Dunlap.Signed-off-by Rob Landley <[email protected]>---
Documentation/DocBook/Makefile | 2 Documentation/DocBook/scsi_midlayer.tmpl | 409 +++++++++++++++++++++
Quoted 7 lines
My only concern with this ATM is its name (SCSI midlayer), but chapter 2 is SCSI upper layer, chap 3 is SCSI midlayer, and chap 4 is SCSI low-level interfaces.
Chapters 2 & 4 are mostly stubs or todo list, which is OK, but if those chapters remain in this docbook, it looks like the docbook name should be changed (maybe later).
How about just scsi.tmpl then?
James
Re: [PATCH] Add Documentation/DocBook/scsi_midlayer.tmpl and update kerneldoc comments and Makefile.
Quoted 10 lines · On Wednesday 07 November 2007 00:47:20 James Bottomley wrote:
Quoted 7 lines · Randy Dunlap
My only concern with this ATM is its name (SCSI midlayer), but chapter 2 is SCSI upper layer, chap 3 is SCSI midlayer, and chap 4 is SCSI low-level interfaces.
Chapters 2 & 4 are mostly stubs or todo list, which is OK, but if those chapters remain in this docbook, it looks like the docbook name should be changed (maybe later).
How about just scsi.tmpl then?
I have no attachment to a specific name. Call it what you like. :)
Rob
Signature · 2 lines
"One of my most productive days was throwing away 1000 lines of code." - Ken Thompson.
PATCH 1/1 scsi: docbook and kernel-doc updates
From: Randy Dunlap <[email protected]>
- Change title to remove "Mid-Layer" since the doc is about all of the SCSI layers.
- Use "SCSI" instead of "scsi" in docbook text.
- Use "*/" to end kernel-doc notation blocks.
- A few other minor typo fixes.
--- Documentation/DocBook/scsi.tmpl | 10 +-- drivers/scsi/scsi.c | 2 drivers/scsi/scsi_error.c | 79 +++++++++++++--------------- drivers/scsi/scsi_transport_srp.c | 3 - 4 files changed, 45 insertions(+), 49 deletions(-)
Documentation/DocBook/scsi.tmpl +5 -5
@@ -4,7 +4,7 @@ <book id="scsimid"> <bookinfo> - <title>SCSI Mid Layer Guide</title> + <title>SCSI Interfaces Guide</title> <authorgroup> <author>
@@ -92,7 +92,7 @@ The SCSI subsystem uses a three layer design, with upper, mid, and low layers. Every operation involving the SCSI subsystem (such as reading a sector from a disk) uses one driver at each of the 3 levels: one - upper layer driver, one lower layer driver, and the scsi midlayer. + upper layer driver, one lower layer driver, and the SCSI midlayer. </para> <para> The SCSI upper layer provides the interface between userspace and the
@@ -154,7 +154,7 @@ <sect2 id="scsi.c"> <title>drivers/scsi/scsi.c</title> - <para>Main file for the scsi midlayer.</para> + <para>Main file for the SCSI midlayer.</para> !Edrivers/scsi/scsi.c </sect2> <sect2 id="scsicam.c">
@@ -182,7 +182,7 @@ <sect2 id="scsi_ioctl.c"> <title>drivers/scsi/scsi_ioctl.c</title> <para> - Handle ioctl() calls for scsi devices. + Handle ioctl() calls for SCSI devices. </para> !Edrivers/scsi/scsi_ioctl.c </sect2>
@@ -287,7 +287,7 @@ <sect1 id="Transport_classes"> <title>Transport classes</title> <para> - Transport classes are service libraries for drivers in the scsi + Transport classes are service libraries for drivers in the SCSI lower layer, which expose transport attributes in sysfs. </para> <sect2 id="Fibre_Channel_transport">
drivers/scsi/scsi.c +1 -1
@@ -933,7 +933,7 @@ EXPORT_SYMBOL(starget_for_each_device);* reference. You must hold the host's host_lock over this call and * any access to the returned scsi_device. * -* Note: The only reason why drivers would want to use this is because +* Note: The only reason why drivers should use this is because * they need to access the device list in irq context. Otherwise you * really want to use scsi_device_lookup_by_target instead. **/
drivers/scsi/scsi_error.c +38 -41
307 lines not on this page · raw message
drivers/scsi/scsi_transport_srp.c +1 -2
@@ -185,11 +185,10 @@ static int srp_host_match(struct attribu/** * srp_rport_add - add a SRP remote port to the device hierarchy -* * @shost: scsi host the remote port is connected to. * @ids: The port id for the remote port. * -* publishes a port to the rest of the system +* Publishes a port to the rest of the system. */ struct srp_rport *srp_rport_add (struct Scsi_Host *shost,struct srp_rport_identifiers *ids)
Re: [PATCH] scsi: docbook and kernel-doc updates
Quoted 9 lines · On Thursday 15 November 2007 17:42:30 Randy Dunlap wrote:
From: Randy Dunlap <[email protected]>
- Change title to remove "Mid-Layer" since the doc is about all of the SCSI layers.
- Use "SCSI" instead of "scsi" in docbook text.
- Use "*/" to end kernel-doc notation blocks.
- A few other minor typo fixes.Signed-off-by Randy Dunlap <[email protected]>
Rob
Signature · 2 lines
"One of my most productive days was throwing away 1000 lines of code." - Ken Thompson.