lkml.org 
[lkml]   [2005]   [Oct]   [22]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateSat, 22 Oct 2005 10:23:39 -0700 (PDT)
FromLuben Tuikov <>
SubjectRe: ioctls, etc. (was Re: [PATCH 1/4] sas: add flag for locally attached PHYs)
--- Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
> Will cmd_per_lun, sg_tablesize, max_sectors, dma_boundary, 
> use_clustering ever have to be adjusted specifically for a SAS hardware?

No hardware SAS chip I know of needs any of those legacy limitations.
Neither BCM8603 nor Fusion MPT.

Those limitations are purely Parallel SCSI.

I just included it, to show proof of concept -- when the architecure and
layering is correct, how easy it is to do it.  But you're right, it is
not needed.

> Obviuosly none of this is required _at the moment_. IOW neither the 
> introduction of a sas_ha_hw_profile nor a pass-through of 
> scsi_host_template down to SAS interconnect drivers is required right 
> now. So why do one or the other now? Isn't it a sensible rule to not 
> solve problems now which do not exist yet?

This is exactly the rule I followed when developing the SAS Transport
Layer for Linux.  Furthermore, _that_ rule, to never overengineer, I learned
from Linux.  Sadly the politics are too deep and that rule applies only
to what is convenient, at least in Linux SCSI.

   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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-10-22 17:26    [from the cache]
©2003-2008