RE: [PATCH 3/3] MidLayer updates - extending scsi_target support
No - there was no discussion of adding scsi targets to linux (per your definition or otherwise). Since the Emulex driver tracks things by target (actually FC remote port) rather than luns, having the ability to have driver data space in the lun didn't help much. Yes, the driver data space could be in the transport-specific FC remote port, but I thought a more generic solution would have been prefered - thus the patch request. At this point, it appears that consensus is against the need for this, especially as it can be handled within the only area needed today - that of the FC transport. -- james s -Original Message- From: Vladislav Bolkhovitin [mailto:[EMAIL PROTECTED] Sent: Sunday, February 06, 2005 9:18 AM To: linux-scsi@vger.kernel.org Cc: Smart, James Subject: Re: [PATCH 3/3] MidLayer updates - extending scsi_target support Please, forgive me my ignorance, it looks like something was happened behind the scene (linux-scsi list), and I missed it. Is support for SCSI targets started to be added in Linux? I mean SCSI targets as the ability to export local devices on a SCSI bus. If so, please consider proposed SCSI target mid-level (SCST) living on http://scst.sourceforge.net. In the next few weeks we are going to clean it a bit and prepare the patch, so it could start being part of some testing tree, probably -mm, although it is stable enough ever for Linus one. BTW, are there any descriptions for current scsi_target support and in which direction it's moving? Vlad [EMAIL PROTECTED] wrote: Patch 3: This patch extends scsi_target support: - Allows for driver-specific data to be allocated along with the target structure and accessible via the starget-hostdata pointer. - Adds scsi target alloc/configure/destory callbacks to the scsi host template. - Rearranges the calling sequences for scsi targets so that the target and slave alloc/configure/destory callbacks are in order (target before slave on alloc/configure). -- James S - 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 3/3] MidLayer updates - extending scsi_target support
On Sun, Feb 06, 2005 at 12:28:17PM -0500, [EMAIL PROTECTED] wrote: Since the Emulex driver tracks things by target (actually FC remote port) rather than luns, having the ability to have driver data space in the lun didn't help much. Yes, the driver data space could be in the transport-specific FC remote port, but I thought a more generic solution would have been prefered - thus the patch request. At this point, it appears that consensus is against the need for this, especially as it can be handled within the only area needed today - that of the FC transport. Well, I disagree with that for certain. I know of a handfull of SPI HBA drivers that would benefit from per-target private data. - 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 3/3] MidLayer updates - extending scsi_target support
the idea behind this is fine, I just don't like the interface. Really a target device is nothing more than a container to SCSI. We already do the transport add/remove calls for targets, I don't see we need other calls duplicating this. So, I think the implementation would look a whole lot better if the fc transport class just exported an interface to get the extra storage for the driver and tacked it on to its allocation. Then you can use the existing mid-layer transport target triggers to do everything you want. This can certainly be transport-specific. However, I assumed the better solution was to make it more generic as there's nothing about this problem that's transport-centric. If a driver only tracks things by target (not lun), it makes a whole lotta sense to allow for per-target data. Please note however, that I recommend the changes for calling sequence be taken in regardless. The issue is that the sdev transport setup and slave alloc calls are made prior to the existence of the starget (thus any starget transport setup call). The starget really needs to be in place beforehand. Let me know - I can revise the patch accordingly. -- James S - 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 3/3] MidLayer updates - extending scsi_target support
[EMAIL PROTECTED] wrote: the idea behind this is fine, I just don't like the interface. Really a target device is nothing more than a container to SCSI. We already do the transport add/remove calls for targets, I don't see we need other calls duplicating this. So, I think the implementation would look a whole lot better if the fc transport class just exported an interface to get the extra storage for the driver and tacked it on to its allocation. Then you can use the existing mid-layer transport target triggers to do everything you want. This can certainly be transport-specific. However, I assumed the better solution was to make it more generic as there's nothing about this problem that's transport-centric. If a driver only tracks things by target (not lun), it makes a whole lotta sense to allow for per-target data. Targets speak the same transport protocol as the HBA. This cannot necessarily be said about logical units. Bridges are being proposed between SAS and SPI in which U160/U320 disks on a SPI bus appear as luns on a single SAS target (i.e. the bridge device). If the initiator wants to speak to the disks then it uses luns (most likely where SPI target ids appear as luns). The initiator may be a little surprised if it queries the protocol specific mode and log pages on those disks (as they will reveal their native SPI transport characteristics). To query and configure the bridge (and perhaps check its protocol specific mode and logs pages) well known logical unit numbers will be used. SCSI targets seem like an important abstraction in their own right, not just containers for lus. 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 3/3] MidLayer updates - extending scsi_target support
On Sat, 2005-01-29 at 09:03 -0500, [EMAIL PROTECTED] wrote: This patch extends scsi_target support: - Allows for driver-specific data to be allocated along with the target structure and accessible via the starget-hostdata pointer. - Adds scsi target alloc/configure/destory callbacks to the scsi host template. - Rearranges the calling sequences for scsi targets so that the target and slave alloc/configure/destory callbacks are in order (target before slave on alloc/configure). the idea behind this is fine, I just don't like the interface. Really a target device is nothing more than a container to SCSI. We already do the transport add/remove calls for targets, I don't see we need other calls duplicating this. So, I think the implementation would look a whole lot better if the fc transport class just exported an interface to get the extra storage for the driver and tacked it on to its allocation. Then you can use the existing mid-layer transport target triggers to do everything you want. 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
