mirror of
https://github.com/SCST-project/scst.git
synced 2026-08-25 00:26:43 +00:00
The website links to stale deployed manuals, generated pages and a QLogic snapshot that is not in the repository. Several feature summaries also describe code that has since changed or disappeared. Commit7aade0a109("Makefile: Make the qla2x00t-32gbit driver the default QLogic FC driver") changed the default QLogic tree. Commit3a8d70b166("- Remove old scst_db stuff which no longer works with even procfs.") removed database-backed scstadmin configuration. Commitd84fc0783d("vdisk_fileio: Add support for asynchronous I/O processing") removed O_DIRECT as a fileio_tgt-only distinction. Linux commit 066465251303 ("tgt: removal") removed scsi_tgt in 2014, turning the website prediction into a completed historical event. Commit10ebf80e7a("Docs update") merged the SGV cache text into doc/scst_pg.sgml. Link website entries to maintained repository sources, use the real lowercase make rpm target, update the affected feature descriptions and remove references to files that are not tracked.
206 lines
9.9 KiB
HTML
206 lines
9.9 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
|
<html>
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
|
|
<meta name="author" content="Daniel Fernandes">
|
|
<meta name="Robots" content="index,follow">
|
|
<link rel="stylesheet" href="images/Orange.css" type="text/css">
|
|
<title>SCST Contributing</title>
|
|
</head>
|
|
|
|
<body>
|
|
<div id="wrap">
|
|
<div id="header">
|
|
<div class="logoimg"></div><h1 id="logo"><span class="orange"> </span></h1>
|
|
<h2 id=slogan>Generic SCSI Target Subsystem for Linux</h2>
|
|
</div>
|
|
|
|
<div id="menu">
|
|
<ul>
|
|
<li><a href="index.html">Home</a></li>
|
|
<li><a href="https://github.com/SCST-project/scst">Main</a></li>
|
|
<li><a href="https://github.com/SCST-project/scst/releases">News</a></li>
|
|
<li><a href="targets.html">Drivers</a></li>
|
|
<li><a href="downloads.html">Downloads</a></li>
|
|
<li id="current"><a href="contributing.html">Contributing</a></li>
|
|
<li><a href="comparison.html">Comparison</a></li>
|
|
<li><a href="users.html">Users</a></li>
|
|
</ul>
|
|
</div>
|
|
|
|
<div id="content-wrap">
|
|
<div id="main">
|
|
<h1>Contributing to SCST</h1>
|
|
|
|
<p>If you would like to contribute to SCST development, you can do in many ways:</p>
|
|
|
|
<ul>
|
|
<li><span>By sending <a href="http://sourceforge.net/donate/index.php?group_id=110471">donations</a>.
|
|
They will be spent on further work making SCST better, including buying new hardware, as well as on providing
|
|
better support and troubleshooting for you. If you want to donate another amount, than listed on the
|
|
provided buttons, you can directly edit URL they are pointing to.</span></li>
|
|
<li><span>By sending patches, which fix bugs or implement new functionality.
|
|
See below a list of possible SCST improvements with some possible
|
|
implementation ideas.</span></li>
|
|
<li><span>By writing or updating various documentation to keep it complete and up to date.
|
|
For instance, <a href="https://github.com/SCST-project/scst/blob/master/doc/scst_pg.sgml">SCST internals description</a> document is
|
|
in some areas quite outdated. Particularly, many functions were renamed since
|
|
time, when it was written. It would be good to bring it up to date.</span></li>
|
|
<li><span>By reporting bugs or other problems.</span></li>
|
|
</ul>
|
|
|
|
<h1>Possible SCST extensions and improvements</h1>
|
|
|
|
<A NAME="SG_LIMIT"></A><h3>Solve SG IO count limitation issue in pass-through mode</h3>
|
|
|
|
<p>In the pass-through mode (i.e. using the pass-through device handlers like
|
|
scst_tape, etc.) SCSI commands, coming from remote initiators,
|
|
are passed to local SCSI hardware on target as is, without any
|
|
modifications. As any other hardware, the local SCSI hardware can not
|
|
handle commands with amount of data and/or segments count in
|
|
scatter-gather array bigger some values. For some commands SCST can
|
|
split them on subcommands and, hence, workaround this problem, but it isn't
|
|
always possible. For instance, for tapes splitting write commands may mean
|
|
corrupting the tape data.</p>
|
|
|
|
<p>If you have this issue you will see
|
|
symptoms like small transfers work well, but large transfers stall and
|
|
messages like: "Unable to complete command due to SG IO count
|
|
limitation" are printed in the kernel logs.</p>
|
|
|
|
<p>The only complete way to fix this problem is to allocate data buffers with number
|
|
of entries inside the SG IO count limitation. In <a href="sgv_big_order_alloc.diff">sgv_big_order_alloc.diff</a>
|
|
you can find a possible way to solve this issue.</p>
|
|
|
|
<p>You can also look at patch
|
|
<a href="sgv_big_order_alloc-sfw5-rc3.diff">sgv_big_order_alloc-sfw5-rc3.diff</a>
|
|
created by Frank Zago for SCST 2.0.0. It was submitted too late to be included in it.
|
|
Update for SCST trunk is welcome!</p>
|
|
|
|
<p>Note, scst_disk handler already implements a workaround for it.</p>
|
|
|
|
<A NAME="MEM_REG"></A><h3>Memory registration</h3>
|
|
|
|
<p>In some cases a target driver might need to register memory used for data buffers in the
|
|
hardware. At the moment, none of SCST target drivers, including InfiniBand SRP target driver,
|
|
need that feature. But in case if in future there is a need in such a feature, it can be easily
|
|
added by extending SCST SGV cache. The SCST SGV cache is a memory management
|
|
subsystem in SCST. It doesn't free to the system each data buffer,
|
|
which is not used anymore, but keeps it for a while to let it be reused by the
|
|
next consecutive command to reduce command processing latency and, hence, improve performance.</p>
|
|
|
|
<p>To support memory buffers registrations, it can be extended by the following way:</p>
|
|
|
|
<p>1. Struct scst_tgt_template would be extended to have 2 new callbacks:</p>
|
|
|
|
<ul>
|
|
|
|
<li><span>int register_buffer(struct scst_cmd *cmd)</span></li>
|
|
|
|
<li><span>int unregister_buffer(unsigned long mem_priv, void *scst_priv)</span></li>
|
|
|
|
</ul>
|
|
|
|
<p>2. SCST core would be extended to have 4 new functions:</p>
|
|
|
|
<ul>
|
|
|
|
<li><span>int scst_mem_registered(struct scst_cmd *cmd)</span></li>
|
|
|
|
<li><span>int scst_mem_deregistered(void *scst_priv)</span></li>
|
|
|
|
<li><span>int scst_set_mem_priv(struct scst_cmd *cmd, unsigned long mem_priv)</span></li>
|
|
|
|
<li><span>unsigned long scst_get_mem_priv(struct scst_cmd *cmd)</span></li>
|
|
|
|
</ul>
|
|
|
|
<p>3. The workflow would be the following:</p>
|
|
|
|
<ol>
|
|
<li><span>If target driver defined register_buffer() and unregister_buffer() callbacks,
|
|
SCST core would allocate a dedicated SGV cache for each instance of struct scst_tgt,
|
|
i.e. target.</span></li>
|
|
|
|
<li><span>When there would be an SGV cache miss in memory buffer for a command allocation,
|
|
SCST would check if register_buffer() callback was defined in the target driver's template
|
|
and, if yes, would call it.</span></li>
|
|
|
|
<li><span>In register_buffer() callback the target driver would do necessary actions to
|
|
start registration of the commands memory buffer.</span></li>
|
|
|
|
<li><span>Upon register_buffer() callback returns, SCST core would suspend processing the
|
|
corresponding command and would switch to the next commands processing.</span></li>
|
|
|
|
<li><span>After the memory registration finished, the target driver would call scst_set_mem_priv()
|
|
to associate the memory buffer with some internal data.</span></li>
|
|
|
|
<li><span>Then the target driver would call scst_mem_registered() and SCST would resume processing
|
|
the command. Functions scst_set_mem_priv() and scst_mem_registered() can be called from inside register_buffer().
|
|
In this case SCST core would continue processing the command immediately without suspending.</span></li>
|
|
|
|
<li><span>After the command finished, the corresponding memory buffer would remain in the
|
|
SGV cache in the registered state and would be reused by the next commands. For each of them
|
|
the target driver can at any time figure out the associated with the registered buffer data
|
|
by using scst_get_mem_priv().</span></li>
|
|
|
|
<li><span>When the SGV cache decide that there is a time to free the memory buffer, it would
|
|
call the target driver's unregister_buffer() callback.</span></li>
|
|
|
|
<li><span>In this callback the target driver would do necessary actions to start deregistration of the
|
|
commands memory buffer.</span></li>
|
|
|
|
<li><span>Upon unregister_buffer() callback returns, SGV cache would suspend freeing the corresponding buffer
|
|
and would switch to other deals it has.</span></li>
|
|
|
|
<li><span>After the memory deregistration finished, the target driver would call scst_mem_deregistered()
|
|
and pass to it scst_priv pointer, received in unregister_buffer(). Then the memory buffer
|
|
would be freed by the SGV cache. Function scst_mem_deregistered() can be called from inside unregister_buffer().
|
|
In this case SGV cache would free the buffer immediately without suspending.
|
|
</span></li>
|
|
</ol>
|
|
|
|
<A NAME="NON_SCSI_TGT"></A><h3>SCST usage with non-SCSI transports</h3>
|
|
|
|
<p>SCST might also be used with non-SCSI speaking transports, like NBD or AoE. Such cooperation
|
|
would allow them to use SCST-emulated backend.</p>
|
|
|
|
<p>For user space targets this is trivial: they simply should use SCST-emulated devices locally
|
|
via scst_local module.</p>
|
|
|
|
<p>For in-kernel non-SCSI target driver it's a bit more complicated. They should implement a small layer,
|
|
which would translate their internal READ/WRITE requests to corresponding SCSI commands and, on the
|
|
way back, SCSI status and sense codes to their internal status codes.</p>
|
|
|
|
<A NAME="GET_CONFIGURATION"></A><h3>GET CONFIGURATION command</h3>
|
|
|
|
<p>SCSI command GET CONFIGURATION is mandatory for SCSI multimedia devices, like CD/DVD-ROMs or
|
|
recorders, see MMC standard. Currently SCST lacks support for it, which leads to problems
|
|
with some programs depending on the result of GET CONFIGURATION command execution.</p>
|
|
|
|
<p>It would be good to add support for it in the SCST core.</p>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<!-- wrap ends here -->
|
|
<!-- footer starts here -->
|
|
<div id="footer">
|
|
<p>© Copyright 2004 - 2021 <b><font color="#EC981F">Vladislav Bolkhovitin, Bart Van Assche & others</font></b>
|
|
Design by: <b><font color="#EC981F">Daniel Fernandes</font></b> </p>
|
|
</div>
|
|
<!-- footer ends here -->
|
|
<!-- Piwik -->
|
|
<script type="text/javascript">
|
|
var pkBaseURL = (("https:" == document.location.protocol) ? "https://apps.sourceforge.net/piwik/scst/" : "http://apps.sourceforge.net/piwik/scst/");
|
|
document.write(unescape("%3Cscript src='" + pkBaseURL + "piwik.js' type='text/javascript'%3E%3C/script%3E"));
|
|
</script><script type="text/javascript">
|
|
piwik_action_name = '';
|
|
piwik_idsite = 1;
|
|
piwik_url = pkBaseURL + "piwik.php";
|
|
piwik_log(piwik_action_name, piwik_idsite, piwik_url);
|
|
</script>
|
|
<object><noscript><p><img src="http://apps.sourceforge.net/piwik/scst/piwik.php?idsite=1" alt="piwik"></p></noscript></object>
|
|
<!-- End Piwik Tag -->
|
|
</body>
|
|
</html>
|