Re: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel

Luben Tuikov wrote:

On 10/03/05 12:48, Jeff Garzik wrote:

No, transport class is its name. Think about a standard object-oriented

Not according to Kconfig:

menu "SCSI Transport Attributes"
	depends on SCSI

config SCSI_SPI_ATTRS
	tristate "Parallel SCSI (SPI) Transport Attributes"
	depends on SCSI
	help
	  If you wish to export transport-specific information about
	  each attached SCSI device to sysfs, say Y.  Otherwise, say N.

config SCSI_FC_ATTRS
	tristate "FiberChannel Transport Attributes"
	depends on SCSI
	help
	  If you wish to export transport-specific information about
	  each attached FiberChannel device to sysfs, say Y.
	  Otherwise, say N.

For FC there is code like the fc_rport stuff which exports a sysfs interface but also does a lot more like probing and queue blocking.

config SCSI_ISCSI_ATTRS
	tristate "iSCSI Transport Attributes"
	depends on SCSI
	help
	  If you wish to export transport-specific information about
	  each attached iSCSI device to sysfs, say Y.
	  Otherwise, say N.

And the iSCSI class does do a lot more now too. This just has not been updated. It handles the userspace to kernel communication, session and connection sysfs interface setup, and there were some patches that added the ability to tell scsi-ml to stop queueing commands to a iscsi driver.

Structures like the fc_rport and iscsi_session are managed by the transport classes so scsi-ml never knows about them (except for that scanning bug). And it is possible to share them between HW and software or partial software solutions. I do agree for some iscsi sitautions having a layer over the eh or command exection where the transport really is more of a layer like your design would be nice (I am not refferring to the code duplication though becuase iSCSI would like some of yrou fixes :), but at the same time there are places where code can be shared between a interface that hides the lower level details and one that implements them in software. Maybe it is not this way for SAS though.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

---

• Follow-Ups:
  • Re: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel
    • From: Jeff Garzik <[email protected]>

• References:
  • Re: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel
    • From: Luben Tuikov <[email protected]>
  • Re: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel
    • From: Jeff Garzik <[email protected]>
  • Re: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel
    • From: Luben Tuikov <[email protected]>
  • Re: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel
    • From: Jeff Garzik <[email protected]>
  • Re: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel
    • From: Luben Tuikov <[email protected]>

• Prev by Date: Re: what's next for the linux kernel?
• Next by Date: Re: [PATCH 5/7] AMD Geode GX/LX support
• Previous by thread: Re: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel
• Next by thread: Re: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel
• Index(es):
  • Date
  • Thread

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]