Re: scsi_device::single_lun name change
On Wed, 2005-02-16 at 10:57 +1000, Douglas Gilbert wrote: > "scsi_target: representation of a scsi target, for now, > this is only used for single_lun devices." This is just above > the definition of the scsi_target structure in scsi_device.h Yes, I suppose that's historical junk now. > Elsewhere in that file scsi_device::single_lun is defined > with this comment: > "Indicates we should only allow I/O to one of the luns for > the device at a time." > That implies that the target must have multiple lus when > single_lun is set :-) > > Is it too late to rename that field to something like: > serialize_lu_io or single_lu_io ? Well, it corresponds to BLIST_SINGLELUN flag, so the naming scheme is currently internally consistent. James - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] target code updates to support scanned targets
On Tue, 2005-02-15 at 16:54 -0800, Joe Scsi wrote: > OK (and sorry if I'm being dense) but does this mean that a network > SCSI transport should make up an "id" for each target port it connects > to and then call scsi_scan_target()? Currently yes ... now that we allow unscanned hosts, it's not strictly necessary; we could allow the target id to be a string with meaning to the driver, but that's for another day. James - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] target code updates to support scanned targets
On Tue, 2005-02-15 at 16:53 -0800, Andrew Vasquez wrote: > Yes, but the parent needs to know if the starget is actually created. > With the fc_rports snapshot I've been working with, I've coded up the > following: Why do you need to know if the scan actually found any LUNs? > > + scsi_scan_target(&rport->dev, rport->channel, rport->scsi_target_id, > + SCAN_WILD_CARD, 0); > + > + dev = container_of(rport->dev.children.next, struct device, node); > + rport->starget = to_scsi_target(dev); can we get rid of this too ... does the rport really need to know if it has a target? > + if (unlikely(!rport->starget)) > dev_printk(KERN_ERR, &rport->dev, TGT_ALLOC_FAILURE_MSG, > __FUNCTION__, shost->host_no); > > so when the rport gets dropped (i.e. fc_remote_port_delete()), a > scsi_remove_target() call can be issued. I'm not entirely thrilled > with the structure-member poking (any other suggestions on how to get > the child, welcomed), but it does work. Well, how about a different format for this, so there's a scsi_remove_target that takes a generic device (analogous to the scsi_scan_target) except that this time if the device isn't a target, we remove all the children of the device that are targets? > Also, the patch neglected to add scsi_scan_target() to an appropriate > header file. Attached patch will cure -- I've added it to > scsi_host.h, may wish to add to scsi_device.h. Yes, it should be in scsi_device.h which is where the scsi target functions currently are. I'll add it. James - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
scsi_device::single_lun name change
While looking at struct scsi_target in a recent lk 2.6 kernel I was confused by this sentence: "scsi_target: representation of a scsi target, for now, this is only used for single_lun devices." This is just above the definition of the scsi_target structure in scsi_device.h Elsewhere in that file scsi_device::single_lun is defined with this comment: "Indicates we should only allow I/O to one of the luns for the device at a time." That implies that the target must have multiple lus when single_lun is set :-) Is it too late to rename that field to something like: serialize_lu_io or single_lu_io ? Doug Gilbert - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] target code updates to support scanned targets
> A driver doesn't allocate a target. In this code, a target device is > purely a LUN container and is managed by the mid-layer. The driver > requests the scan of a target by parent device, channel and id. This > request for a scan creates and parents the target object, but reaps it > again if no actual LUNs are discovered. OK (and sorry if I'm being dense) but does this mean that a network SCSI transport should make up an "id" for each target port it connects to and then call scsi_scan_target()? Thanks, Joe - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] target code updates to support scanned targets
On Tue, 15 Feb 2005, James Bottomley wrote: > On Tue, 2005-02-15 at 15:29 -0800, Joe Scsi wrote: > > I see the internal changes to scsi_scan.c that this refers to, but > > I'm not totally clear on what a driver should do to allocate a target > > and scan it when it finds out about a new target port. > > A driver doesn't allocate a target. In this code, a target device is > purely a LUN container and is managed by the mid-layer. The driver > requests the scan of a target by parent device, channel and id. This > request for a scan creates and parents the target object, but reaps it > again if no actual LUNs are discovered. > Yes, but the parent needs to know if the starget is actually created. With the fc_rports snapshot I've been working with, I've coded up the following: + scsi_scan_target(&rport->dev, rport->channel, rport->scsi_target_id, + SCAN_WILD_CARD, 0); + + dev = container_of(rport->dev.children.next, struct device, node); + rport->starget = to_scsi_target(dev); + if (unlikely(!rport->starget)) dev_printk(KERN_ERR, &rport->dev, TGT_ALLOC_FAILURE_MSG, __FUNCTION__, shost->host_no); so when the rport gets dropped (i.e. fc_remote_port_delete()), a scsi_remove_target() call can be issued. I'm not entirely thrilled with the structure-member poking (any other suggestions on how to get the child, welcomed), but it does work. Also, the patch neglected to add scsi_scan_target() to an appropriate header file. Attached patch will cure -- I've added it to scsi_host.h, may wish to add to scsi_device.h. -- AV diff -Nurdp -X ../8.x/dontdiff-bk scsi-rport-orig/include/scsi/scsi_host.h scsi-rport/include/scsi/scsi_host.h --- scsi-rport-orig/include/scsi/scsi_host.h2005-02-15 17:10:42.0 -0800 +++ scsi-rport/include/scsi/scsi_host.h 2005-02-15 15:45:21.0 -0800 @@ -575,6 +575,8 @@ extern void scsi_remove_host(struct Scsi extern struct Scsi_Host *scsi_host_get(struct Scsi_Host *); extern void scsi_host_put(struct Scsi_Host *t); extern struct Scsi_Host *scsi_host_lookup(unsigned short); +extern void scsi_scan_target(struct device *, unsigned int, unsigned int, + unsigned int, int); extern u64 scsi_calculate_bounce_limit(struct Scsi_Host *); - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] target code updates to support scanned targets
On Tue, 2005-02-15 at 15:29 -0800, Joe Scsi wrote: > I see the internal changes to scsi_scan.c that this refers to, but > I'm not totally clear on what a driver should do to allocate a target > and scan it when it finds out about a new target port. A driver doesn't allocate a target. In this code, a target device is purely a LUN container and is managed by the mid-layer. The driver requests the scan of a target by parent device, channel and id. This request for a scan creates and parents the target object, but reaps it again if no actual LUNs are discovered. James - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] target code updates to support scanned targets
James, this looks like it would be really useful for my driver and I hope it goes upstream soon. I do have one question. > 2. rejig the scanning code to do target scanning via a parent generic > device rather than the HCTL numbers. I see the internal changes to scsi_scan.c that this refers to, but I'm not totally clear on what a driver should do to allocate a target and scan it when it finds out about a new target port. Thanks, Joe - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] target code updates to support scanned targets
Since everyone's been asking for the ability to do target scanning, I
took a look at how this might be done in our current infrastructure.
The attached patch does three things:
1. Pulls target allocation forward so it's now allocated and destroyed
as a separate entity instead of being bound into device (LUN) allocation
2. rejig the scanning code to do target scanning via a parent generic
device rather than the HCTL numbers.
3. Exported the modified scsi_scan_target and scsi_remove_target.
4. moved our sibling lists into the target.
Immediately for iscsi and fc, this should give the ability to parent a
scanned target to something not necessarily a scsi host (needed for the
rport work) and also both of you should now be able to remove
scsi_scan_host() from your drivers.
Anyway, give it the once over and tell me what you think.
James
= drivers/scsi/hosts.c 1.107 vs edited =
--- 1.107/drivers/scsi/hosts.c 2005-01-18 13:15:06 -06:00
+++ edited/drivers/scsi/hosts.c 2005-02-13 18:29:58 -06:00
@@ -216,6 +216,7 @@
spin_lock_init(&shost->default_lock);
scsi_assign_lock(shost, &shost->default_lock);
INIT_LIST_HEAD(&shost->__devices);
+ INIT_LIST_HEAD(&shost->__targets);
INIT_LIST_HEAD(&shost->eh_cmd_q);
INIT_LIST_HEAD(&shost->starved_list);
init_waitqueue_head(&shost->host_wait);
= drivers/scsi/scsi_lib.c 1.148 vs edited =
--- 1.148/drivers/scsi/scsi_lib.c 2005-02-01 10:49:23 -06:00
+++ edited/drivers/scsi/scsi_lib.c 2005-02-14 17:05:02 -06:00
@@ -365,10 +365,11 @@
{
struct Scsi_Host *shost = current_sdev->host;
struct scsi_device *sdev, *tmp;
+ struct scsi_target *starget = scsi_target(current_sdev);
unsigned long flags;
spin_lock_irqsave(shost->host_lock, flags);
- scsi_target(current_sdev)->starget_sdev_user = NULL;
+ starget->starget_sdev_user = NULL;
spin_unlock_irqrestore(shost->host_lock, flags);
/*
@@ -380,10 +381,12 @@
blk_run_queue(current_sdev->request_queue);
spin_lock_irqsave(shost->host_lock, flags);
- if (scsi_target(current_sdev)->starget_sdev_user)
+ if (starget->starget_sdev_user)
goto out;
- list_for_each_entry_safe(sdev, tmp, ¤t_sdev->same_target_siblings,
+ list_for_each_entry_safe(sdev, tmp, &starget->devices,
same_target_siblings) {
+ if (sdev == current_sdev)
+ continue;
if (scsi_device_get(sdev))
continue;
= drivers/scsi/scsi_scan.c 1.140 vs edited =
--- 1.140/drivers/scsi/scsi_scan.c 2005-01-18 13:15:06 -06:00
+++ edited/drivers/scsi/scsi_scan.c 2005-02-15 16:11:55 -06:00
@@ -200,12 +200,12 @@
* Return value:
* scsi_Device pointer, or NULL on failure.
**/
-static struct scsi_device *scsi_alloc_sdev(struct Scsi_Host *shost,
- uint channel, uint id, uint lun, void *hostdata)
+static struct scsi_device *scsi_alloc_sdev(struct scsi_target *starget,
+ unsigned int lun, void *hostdata)
{
struct scsi_device *sdev;
- unsigned long flags;
int display_failure_msg = 1, ret;
+ struct Scsi_Host *shost = dev_to_shost(starget->dev.parent);
sdev = kmalloc(sizeof(*sdev) + shost->transportt->device_size,
GFP_ATOMIC);
@@ -217,9 +217,9 @@
sdev->model = scsi_null_device_strs;
sdev->rev = scsi_null_device_strs;
sdev->host = shost;
- sdev->id = id;
+ sdev->id = starget->id;
sdev->lun = lun;
- sdev->channel = channel;
+ sdev->channel = starget->channel;
sdev->sdev_state = SDEV_CREATED;
INIT_LIST_HEAD(&sdev->siblings);
INIT_LIST_HEAD(&sdev->same_target_siblings);
@@ -227,6 +227,9 @@
INIT_LIST_HEAD(&sdev->starved_entry);
spin_lock_init(&sdev->list_lock);
+ sdev->sdev_gendev.parent = get_device(&starget->dev);
+ sdev->sdev_target = starget;
+
/* usually NULL and set by ->slave_alloc instead */
sdev->hostdata = hostdata;
@@ -248,8 +251,12 @@
spin_lock_init(&sdev->sdev_lock);
sdev->request_queue = scsi_alloc_queue(sdev);
- if (!sdev->request_queue)
- goto out_free_dev;
+ if (!sdev->request_queue) {
+ /* release fn is set up in scsi_sysfs_device_initialise, so
+* have to free and put manually here */
+ put_device(&starget->dev);
+ goto out;
+ }
sdev->request_queue->queuedata = sdev;
scsi_adjust_queue_depth(sdev, 0, sdev->host->cmd_per_lun);
@@ -269,32 +276,117 @@
}
}
- /* NOTE: this target initialisation code depends critically on
-* lun scanning being sequential. */
- if (scsi_sysfs_target_initialize(sdev))
- goto out_remove_siblings;
-
return sdev;
Re: [PATCH] cpnvert scsi_debug to use virtual host bus
Douglas Gilbert wrote: Mike Christie wrote: The attach patch converts scsi_debug to use the virtual scsi bus. It was built against scsi-rc-fixes-2.6. The interface has changed a little. Here is an example of adding and removing a single host: cd /sys/bus/scsi_host/drivers/scsi_debug [EMAIL PROTECTED] scsi_debug]# ls add_host dev_size_mb every_nth module num_parts opts scsi_level delay dsense max_luns num_hosts num_tgts ptype [EMAIL PROTECTED] scsi_debug]# echo 1 > add_host [EMAIL PROTECTED] scsi_debug]# ls add_host dev_size_mb every_nth module num_parts opts scsi_level delay dsense max_luns num_hosts num_tgts ptype virt_host4 [EMAIL PROTECTED] scsi_debug]# cd virt_host4/ [EMAIL PROTECTED] virt_host4]# ls detach_state driver host4 power remove_host [EMAIL PROTECTED] virt_host4]# echo 1 > remove_host Mike, I have noticed a few differences in the scsi_debug driver with this patch applied. Firstly, when loaded the scsi_debug driver has no hosts and thus no devices. Previously it defaulted to 1 host, 1 target and 1 lun (hence 1 device). Now a user needs to do something like: $ modprobe scsi_debug $ cd /sys/bus/scsi_host/drivers/scsi_debug $ echo 42 > add_host This is just a result of me trying to emulate normal HW drivers. For example I did not see any that would add the bus's device (the device equivalent to a pci_dev for example), so this is why I was always just doing the additions from userspace. I can break out part of scsi_host_driver_add_host and export it so LLDs can call it and add hosts from the kernel for scsi_debug. The next issue is the number passed to "add_host". It doesn't matter, one host is added. When add_host belonged to scsi_debug the number and sign of the value sent to add_host was significant (and a negative number tried to remove that number of hosts). Perhaps we could get that capability back by making "num_hosts" writeable. I can easily add both behaviors back to the "add_host" attr. Otherwise it looks good and fixes the "pseudo" bus problem which prevented two or more drivers using the "pseudo" bus at the same time. Doug Gilbert - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] add scsi changer driver
[this should go to linux-scsi]
> +#include
not needed.
> +#include
I doubt you'll need this one.
> +#include
> +
> +#include /* here are all the ioctls */
should always go before
> +#define MAJOR_NR SCSI_CHANGER_MAJOR
please kill this one
> +#include "scsi.h"
never use this header but always the
> +MODULE_SUPPORTED_DEVICE("sch");
no needed thsese days
> +static int dt_id[CH_DT_MAX] = { [ 0 ... (CH_DT_MAX-1) ] = -1 };
> +static int dt_lun[CH_DT_MAX];
> +module_param_array(dt_id, int, NULL, 0444);
> +module_param_array(dt_lun, int, NULL, 0444);
> +
> +/* tell the driver about vendor-specific slots */
> +static int vendor_firsts[CH_TYPES-4];
> +static int vendor_counts[CH_TYPES-4];
> +module_param_array(vendor_firsts, int, NULL, 0444);
> +module_param_array(vendor_counts, int, NULL, 0444);
> +
> +static char *vendor_labels[CH_TYPES-4] = {
> + "v0", "v1", "v2", "v3"
> +};
> +// module_param_string_array(vendor_labels, NULL, 0444);
> +
> +#define dprintk(fmt, arg...)if (debug) \
> +printk(KERN_DEBUG "%s: " fmt, ch->name, ##arg)
> +#define vprintk(fmt, arg...)if (verbose) \
> +printk(KERN_INFO "%s: " fmt, ch->name, ##arg)
> +
> +/* --- */
> +static int ioctl32_register(void)
> +{
> + unsigned int i;
> + int err;
> +
> + for (i = 0; i < ARRAY_SIZE(ioctl32_cmds); i++) {
> + err = register_ioctl32_conversion(ioctl32_cmds[i].cmd,NULL);
> + if (err >= 0)
> + ioctl32_cmds[i].reg++;
> + }
> + return 0;
> +}
please implement ->compat_ioctl instead.
> + int errno, retries = 0, timeout;
> + DECLARE_COMPLETION(wait);
> + Scsi_Request *sr;
> +
> + sr = scsi_allocate_request(ch->device, GFP_ATOMIC);
wouldn't a GFP_KERNEL do just fine?
> + if (NULL == sr)
> + return -ENOMEM;
normal kernel style would be
if (!s)
return -ENOMEM;
> + list_for_each(item,&ch_devlist) {
> + tmp = list_entry(item, scsi_changer, list);
list_for_each_entry
> + list_for_each(item,&ch_devlist) {
> + tmp = list_entry(item, scsi_changer, list);
dito
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LUN discovery by SCSI midlayer?
> Can you take a look at the patches I posted last week and see if that > would work for you? Hmm, I'm not sure. The issue I have is that I know when target ports appear and disappear, and I'd like to use some general SCSI midlayer stuff to discover what LUNs are behind a target port. So if I have to know the full HCTL then that doesn't really help me. It seems kind of ugly if I have to do the REPORT_LUNs command myself and manually call scsi_add_device() for each LUN. (Disappearing target ports seem easier to handle, because I can keep a list of LUNs per target port and call scsi_remove_device() on each LUN) Thanks, Joe - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scsi disk registration - double messages
On Tue, Feb 15, 2005 at 02:33:35PM +, Matthew Wilcox wrote:
> On Tue, Feb 15, 2005 at 12:01:11PM +0200, Meelis Roos wrote:
> > The messages about registration of sda appear tiwice for some reason. This
> > is only cosmetic but still a little strange:
>
> Yes, that happens for everyone.
I posted before but no replies:
Al's log for the patch says "Work around devices with bogus media change
indication on the first open".
What bogus device? Why not put the change in the driver or black list
the device, rather than doing so for all block devices?
This worked fine for me, but I might break with the bogus media:
diff -uprN -X /home/patman/dontdiff linux-2.6.11-rc1/fs/partitions/check.c
no-double-sd-linux-2.6.11-rc1/fs/partitions/check.c
--- linux-2.6.11-rc1/fs/partitions/check.c Fri Dec 24 13:35:28 2004
+++ no-double-sd-linux-2.6.11-rc1/fs/partitions/check.c Fri Jan 21 11:19:00 2005
@@ -375,8 +375,6 @@ int rescan_partitions(struct gendisk *di
bdev->bd_invalidated = 0;
for (p = 1; p < disk->minors; p++)
delete_partition(disk, p);
- if (disk->fops->revalidate_disk)
- disk->fops->revalidate_disk(disk);
if (!get_capacity(disk) || !(state = check_partition(disk, bdev)))
return 0;
for (p = 1; p < state->limit; p++) {
-- Patrick Mansfield
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [KJ] [PATCH][RESUBMIT][11/21] drivers/scsi/* - compile warning cleanup
On Tue, 2005-02-15 at 14:09 +, Matthew Wilcox wrote: > Actually, for 53c700, I think this *is* the right fix. Unless we want to > move it away from using host->base (which is marked as "legacy crap", so > maybe we do). I guess pushing it into hostdata is the preferred way? Well, no it's not really. If you look at 53c700, what it's actually doing is precisely what the iomem resources do (i.e. trying to use a cookie or flag to determine if it's doing mem or io reads/writes). What needs to happen to this driver is to convert it to using the new iomem infrastructure and remove its original implementation. James - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [KJ] [PATCH][RESUBMIT][11/21] drivers/scsi/* - compile warning cleanup
On Tue, Feb 15, 2005 at 02:09:02PM +, Matthew Wilcox wrote: > On Tue, Feb 15, 2005 at 10:39:59AM +, Christoph Hellwig wrote: > > > - return readb(host->base + (reg^bE)); > > > + return readb((volatile void __iomem *)(host->base + (reg^bE))); > > > > Again, no. Stop casting to void __iomem pointers, please don't submit > > a patch like this one again ever. > > Actually, for 53c700, I think this *is* the right fix. Unless we want to > move it away from using host->base (which is marked as "legacy crap", so > maybe we do). I guess pushing it into hostdata is the preferred way? Yes. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scsi disk registration - double messages
On Tue, Feb 15, 2005 at 12:01:11PM +0200, Meelis Roos wrote: > The messages about registration of sda appear tiwice for some reason. This > is only cosmetic but still a little strange: Yes, that happens for everyone. -- "Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception." -- Mark Twain - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [KJ] [PATCH][RESUBMIT][11/21] drivers/scsi/* - compile warning cleanup
On Tue, Feb 15, 2005 at 10:39:59AM +, Christoph Hellwig wrote: > > - return readb(host->base + (reg^bE)); > > + return readb((volatile void __iomem *)(host->base + (reg^bE))); > > Again, no. Stop casting to void __iomem pointers, please don't submit > a patch like this one again ever. Actually, for 53c700, I think this *is* the right fix. Unless we want to move it away from using host->base (which is marked as "legacy crap", so maybe we do). I guess pushing it into hostdata is the preferred way? -- "Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception." -- Mark Twain - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LUN discovery by SCSI midlayer?
On Mon, Feb 14, 2005 at 08:35:25PM -0800, Joe Scsi wrote: > Hi, > > I'm working on a driver for a SCSI protocol that is transported over a > network. > My basic plan is that when the driver is loaded, it will create a SCSI > host structure > for its initiator port. Then target ports will be discovered > asynchronously (and > may appear/disappear as target devices come and go on the network). > > I'm wondering what the best way to handle LUN discovery is. Unfortunately it > seems that scsi_add_device() can only add a single LUN at a time. However, > for my protocol, I see target ports and then need to find the LUNs. So far > I've > come up with a couple of ideas but I'm not totally happy with either: > > (ugly) Do all the REPORT_LUNs stuff in my driver every time I find a new > target port, or > > (ab)use the "channel" index and call scsi_scan_single_target() every time > I connect to a new target port. This seems OK but I'm a little put off by > the > fact that a quick grep shows no callers of scsi_scan_single_target in the > current kernel tree. > > So what is the correct way to handle this? I'm sure the FC and iSCSI people > must have dealt with a similar issue. Can you take a look at the patches I posted last week and see if that would work for you? http://marc.theaimsgroup.com/?l=linux-scsi&m=110780092314985&w=2 See then the megaraid_mbox.c driver patch in the thread for how it converts logical drive numbers into HCTL values and invokes the hotplug subsystem. In your case, you'd use whatever your addressing mechanism is, and convert it into HCTL before invoking the hotplug calls. Then you've got 2 options: 1) if you have a userspace app that knows when LUNs appear and disappear, then you write to /sys/class/scsi_host/hostN/lun_found (akin to logical_drive_created). 2) if your driver is what sees LUN arrivals/removals on the topology, then the driver just invokes the hotplug calls directly rather than expecting the event to originate via a sysfs file. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] SCSI Enclosure Services (SES) simulator
SCSI Enclosure Services (SES) permit "the management and sense the state of power supplies, cooling devices, displays, indicators, individual drives, and other non-SCSI elements installed in an enclosure". The scsi_ses adapter driver simulates a SES device. The default action is to appear as a disk (actually an 8 MB ramdisk) with associated Enclosure Services. This is similar to a fibre channel disk with a SCA-2 connector which includes an Enclosure Services Interface (ESI). Alternatively the scsi_ses driver can simulate a simple SES device. This SES simulator is closely related to the scsi_debug driver. Unlike scsi_debug which can simulate many disks (or other scsi device types), scsi_ses simulates a single disk with an attached SES device. Alternatively it can simulate a freestanding SES device when the "ses_only=1" parameter is given. Further information, usage examples and patches against lk 2.6.11-rc4 can be found at http://sg.torque.net/sg/scsi_ses.html RFC: Does this driver warrant inclusion in the lk 2.6 series? The current scsi_ses patches do not take into account Mike Christie's "scsi bus for virtual drivers" changes. These can be easily applied and will bring the same advantages as they do to the existing scsi_debug and iSCSI drivers. Doug Gilbert + Zacharia Mathew - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
scsi disk registration - double messages
This is 2.6.11-rc4 on Sun SparcStation5 with onbpard ESP scsi, one 2.1G disk and one cdrom. The messages about registration of sda appear tiwice for some reason. This is only cosmetic but still a little strange: eth0: LANCE 08:00:20:90:36:e5 esp0: IRQ 36 SCSI ID 7 Clk 40MHz CCYC=25000 CCF=8 TOut 167 NCR53C9XF(espfast) ESP: Total of 1 ESP hosts found, 1 actually in use. scsi0 : Sparc ESP100A-FAST Vendor: IBM Model: DCAS32160SUN2.1G Rev: S65A Type: Direct-Access ANSI SCSI revision: 02 Vendor: TOSHIBA Model: XM5701TASUN12XCD Rev: 0997 Type: CD-ROM ANSI SCSI revision: 02 esp0: target 3 [period 100ns offset 15 10.00MHz FAST SCSI-II] SCSI device sda: 4226725 512-byte hdwr sectors (2164 MB) SCSI device sda: drive cache: write through SCSI device sda: 4226725 512-byte hdwr sectors (2164 MB) SCSI device sda: drive cache: write through sda: sda1 sda2 sda3 sda4 Attached scsi disk sda at scsi0, channel 0, id 3, lun 0 CONFIG_SCSI=y # CONFIG_SCSI_PROC_FS is not set CONFIG_BLK_DEV_SD=y # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set CONFIG_BLK_DEV_SR=m CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_CHR_DEV_SG=m CONFIG_SCSI_MULTI_LUN=y # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set # CONFIG_SCSI_SPI_ATTRS is not set # CONFIG_SCSI_FC_ATTRS is not set # CONFIG_SCSI_ISCSI_ATTRS is not set # CONFIG_SCSI_SATA is not set # CONFIG_SCSI_PPA is not set # CONFIG_SCSI_IMM is not set # CONFIG_SCSI_QLOGICPTI is not set # CONFIG_SCSI_DEBUG is not set CONFIG_SCSI_SUNESP=y -- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
