> 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
