[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <46717E77.3050706@garzik.org>
Date: Thu, 14 Jun 2007 13:44:23 -0400
From: Jeff Garzik <jeff@...zik.org>
To: Kristen Carlson Accardi <kristen.c.accardi@...el.com>
CC: James Bottomley <James.Bottomley@...elEye.com>,
linux-ide@...r.kernel.org, linux-scsi@...r.kernel.org,
linux-kernel@...r.kernel.org, htejun@...il.com,
arjan@...ux.intel.com
Subject: Re: [patch 2a/3] Expose Power Management Policy option to users
Kristen Carlson Accardi wrote:
> Ok - sorry for my ignorance about SCSI - but my sources (i.e. Arjan) tell
> me that the problem is that Link in ATA land means something different than
> Link in SCSI land, and that what I really need to do is leave this code under
> the Host class, but rename it to something that more accurately reflects
> what it means under SCSI.
James' analogy holds, and is even more true once SATA Port Multipliers
are in the picture. Then you have remote SATA phys. And James has
essentially stated a long term libata problem: libata wants its own ATA
transport class, and perhaps a cleaning-up and coalescing of the
in-kernel SATA phy objects and processes.
The main difference is that SATA doesn't have to worry about target phys
and initiator phys, largely just the initiator phy. And phys in SATA
don't have unique identifiers (WWNs).
I don't think we should delay ALPM in order to complete phy objects and
an ATA transport class. But OTOH a transport class may be the best
place to put these new sysfs nodes. But#2, that train of logic leads
one down the road of implementing a minimal ATA transport class across
all supported ATA devices, which is something that probably only James
is an expert at (transport classes that is, not ATA).
> Should I rename the file to "segment_power_management_policy"?
No.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists