1. 17 10月, 2005 1 次提交
  2. 15 8月, 2005 1 次提交
    • J
      [SCSI] correct transport class abstraction to work outside SCSI · d0a7e574
      James Bottomley 提交于
      I recently tried to construct a totally generic transport class and
      found there were certain features missing from the current abstract
      transport class.  Most notable is that you have to hang the data on the
      class_device but most of the API is framed in terms of the generic
      device, not the class_device.
      
      These changes are two fold
      
      - Provide the class_device to all of the setup and configure APIs
      - Provide and extra API to take the device and the attribute class and
        return the corresponding class_device
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      d0a7e574
  3. 09 8月, 2005 1 次提交
    • J
      [SCSI] fix target scanning oops with fc transport class · 5c44cd2a
      James.Smart@Emulex.Com 提交于
      We have some nasty issues with 2.6.12-rc6. Any request to scan on
      the lpfc or qla2xxx FC adapters will oops. What is happening is the
      system is defaulting to non-transport registered targets, which
      inherit the parent of the scan. On this second scan, performed by
      the attribute, the parent becomes the shost instead of the rport.
      The slave functions in the 2 FC adapters use starget_to_rport()
      routines, which incorrectly map the shost as an rport pointer.
      
      Additionally, this pointed out other weaknesses:
      - If the target structure is torn down outside of the transport,
        we have no method for it to be regenerated at the proper parent.
      - We have race conditions on the target being allocated by both
        the midlayer scan (parent=shost) and by the fc transport
        (parent=rport).
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      5c44cd2a
  4. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4