Re: ioctls, etc. (was Re: [PATCH 1/4] sas: add flag for locally attached PHYs)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/22/05 13:38, Sergey Panov wrote:
>   I just was trying to point out that Luben's transport "layers" in
> place of transport "modules-appendages" simplifies that
> migration/evolution.

True. "modules-appendages" just makes everything messy.  There is
so much SPI in the host template... Take for example recovery,
or as Linux SCSI calls it Error Handling (EH).

EH in Linux SCSI is SPI.  This is a fact, and anyone can look at the
code to convince themselves.

In order to properly get rid ourselves of HCIL, recovery should
be offloaded to the transport _layer_ which communicates with
the transport/interconnect to get things going, as shown in the SAS
Transport Stack at the link in my signature, USB* or SBP subsystems.

* I've been asking Alan to properly implement USB recovery
in the USB Storage subsystem...  Maybe one day...

That is, the layer above knows nothing of the layer below, but
each layer provides well defined functionality, and they all
work in tandem.  This is exactly what allows for quick growth
and rich future (of a design).

In such a design, SCSI Core would be very small and the task
paths would be very straightforward as shown in the SAS Transport
Stack in the link in my signature, USB or SBP subsystems.

BTW, "modules-appendages" very truly describes the current state
of Linux SCSI and this can be seen from, for example the scsi host
structure, where those "modules-appendages" are "hooked".

	Luben
-- 
http://linux.adaptec.com/sas/
http://www.adaptec.com/sas/
-
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/

[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]
  Powered by Linux