theory it is possible that scst_tgt_get_tgt_priv() is invoked before
scst_register_target() returns. The patch below implements such a check and
also removes some superfluous casts.
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@2691 d57e44dd-8a1f-0410-8b47-8ef2f437770f
versions of the kernel. Also, use correct specifiers in some places, ie %zd
where a negative number could be printed.
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@2149 d57e44dd-8a1f-0410-8b47-8ef2f437770f
style fix conforms to the kernel coding standard and uses if (!xxx) rather
than if (NULL == xxx).
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@2138 d57e44dd-8a1f-0410-8b47-8ef2f437770f
seems to have removed the setting of hpnt->max_id, so it seems the default is
7. Set it to 0 because we only want one ID on the device, and we don't do
any checking ...
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@2110 d57e44dd-8a1f-0410-8b47-8ef2f437770f
Also, this approach changes the default behavior for people who are using
CONFIG_SCST_PROC because the default was that a single host/tgt was added,
but now they have to change their /etc/modules.d/scst.conf or whatever to
add add_default_tgt=1.
I am not sure that is a good thing.
With the last few commits and this one, I have tested on 2.6.34.1 and 2.6.28
and things seem to work. I am now looking at the problem Vlad reported with
CONFIG_SCST_PROC where local devices show up under SCSI bus or device from 0
to 7.
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@2108 d57e44dd-8a1f-0410-8b47-8ef2f437770f
oops when we try to unload scst_local. This is because we were unregistering
the driver if we did not add a default target, but we try to do that again
when we try to unload the driver.
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@2101 d57e44dd-8a1f-0410-8b47-8ef2f437770f
root device rather than using a statically allocated structure in the driver.
Tested with 2.6.24 ... now testing with an earlier version.
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@2100 d57e44dd-8a1f-0410-8b47-8ef2f437770f
kernel 2.6.31, not since kernel 2.6.28. See also commit fddd520122953550ec2c8b60e7ca0d0f0d115d97.
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@2094 d57e44dd-8a1f-0410-8b47-8ef2f437770f
- Add sessions (SCSI hosts) creation/delete commands as well as fixes and cleanups
- Docs updated
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@2073 d57e44dd-8a1f-0410-8b47-8ef2f437770f
- Multi-transport support added to scst_local
- Sysfs attributes "version" and "trace_level" added to scst_local
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@2060 d57e44dd-8a1f-0410-8b47-8ef2f437770f
actually need it. This should improve performance on those versions of Linux
that do not need this.
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@2036 d57e44dd-8a1f-0410-8b47-8ef2f437770f
there seems to be a problem with the Linux SCSI stack because when we delete a
LUN on the target, it does not get deleted from Linux. Still investigating.
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@1947 d57e44dd-8a1f-0410-8b47-8ef2f437770f
TRACE_DBG("Created tid '%08lX'", (unsigned long)&tr_id[4]);
is wrong. All it will do is print the address of the fifth byte in the tr_id.
It should cast to an unsigned long * and deref it, at least. However, I have
anothe change that prints out the tr_id as a SAS address.
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@1934 d57e44dd-8a1f-0410-8b47-8ef2f437770f
use an OUI that I think is not currently in use, so it seems unlikely that we
will clash with anyone else, but you never know. I might have to change it
later.
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@1928 d57e44dd-8a1f-0410-8b47-8ef2f437770f
