On Fri, Aug 26, 2005 at 03:24:06PM -0400, Jeff Garzik wrote:
Luben Tuikov wrote:
Even simpler: the transport layer, calls SCSI Core, saying: Hey here is
a pointer to struct scsi_domain_device. If you want, you an send REPORT
LUNS and other things to it.
For the SG_IO ioctl, /dev/sg and
On 08/29/05 13:11, Christoph Hellwig wrote:
On Fri, Aug 26, 2005 at 03:24:06PM -0400, Jeff Garzik wrote:
Luben Tuikov wrote:
Even simpler: the transport layer, calls SCSI Core, saying: Hey here is
a pointer to struct scsi_domain_device. If you want, you an send REPORT
LUNS and other things to
On Mon, Aug 29, 2005 at 01:20:50PM -0400, Luben Tuikov wrote:
What's a scsi_domain_device? Anyway, we don't need any HCIL tuple for
all of the above. SG_IO is done on a blockdevice node, /dev/sg is done
on a chardevice node. Each of them are attached to a request_queue that's
known at
On 08/29/05 13:16, Christoph Hellwig wrote:
No need to do silly renaming, but yes, moving creating of scsi_target
I'd do the silly renaming. I'd also create struct scsi_domain_device,
and do scsi_register_domain_device(). You know, clean slate...
structures to the transport does make
On Mon, 2005-08-29 at 18:16 +0100, Christoph Hellwig wrote:
No need to do silly renaming, but yes, moving creating of scsi_target
structures to the transport does make sense. It's kinda implicit
in the todo list I posted. I also don't really see the point of
the embedded kobject.
You might
On 08/29/05 13:31, Luben Tuikov wrote:
On 08/29/05 13:16, Christoph Hellwig wrote:
No need to do silly renaming, but yes, moving creating of scsi_target
I'd do the silly renaming. I'd also create struct scsi_domain_device,
and do scsi_register_domain_device(). You know, clean slate...
On 08/26/05 21:53, Jeff Garzik wrote:
Luben Tuikov wrote:
On 08/26/05 15:24, Jeff Garzik wrote:
Luben Tuikov wrote:
Even simpler: the transport layer, calls SCSI Core, saying: Hey here is
a pointer to struct scsi_domain_device. If you want, you an send REPORT
LUNS and other things to it.
On 08/26/05 21:39, Jeff Garzik wrote:
Luben Tuikov wrote:
On 08/26/05 14:48, Jeff Garzik wrote:
No host numbers, no routing information. This is all
transparent to SCSI Core, and NONE of its business.
Routing is an essential part of the SCSI core's duties.
[I'm not a big fan of reading
Jeff Garzik wrote:
(host,string) could succeed in transporting both HCIL and non-HCIL
target identifiers.
What is the meaning of host there?
--
Stefan Richter
-=-=-=-= =--- ===-=
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a
Jeff Garzik wrote:
Luben Tuikov wrote:
I never contended that userspace should be moved away from HCIL.
Then, by implication, SAS and FC must continue to maintain HCIL-device
maps.
Yes, but not in the SAS/ FC/ iSCSI/ USB/ SBP-2/... low-level. HCIL does
not exist there. HCIL is only a
Jeff Garzik wrote:
An in-kernel C pointer, to a SCSI target device, is
not sufficient in all cases to address a target. This plays out most
often in userland interfaces such as ioctls.
The C pointer is all the interface between core and low-level needs.
All other means of addressing (IDs,
On 08/24/05 05:12, Christoph Hellwig wrote:
On Tue, Aug 23, 2005 at 08:02:39PM -0400, Luben Tuikov wrote:
In effect FC tells SCSI Core: here is a device I do not know anything
about, other than the fact that it is on the fabric and it has
a SCSI Target (or Initiator) Port: how you get to is is
On 08/25/05 16:06, Jeff Garzik wrote:
Stefan Richter wrote:
Luben Tuikov wanted...
to move _away_ from HCIL. So that addressing of devices in SCSI Core
is _completely_ independent of addressing at the protocol layer.
I second that.
A move away from forced HCIL addressing would be a
On Fri, 2005-08-26 at 12:43 -0400, Luben Tuikov wrote:
A move away from forced HCIL addressing would be a good thing.
However, its impossible to completely move away from addressing, as
userspace and the SCSI core need ways to route CDBs to devices based on
address.
They can use
Luben Tuikov wrote:
On 08/26/05 13:22, James Bottomley wrote:
On Fri, 2005-08-26 at 12:43 -0400, Luben Tuikov wrote:
A move away from forced HCIL addressing would be a good thing.
However, its impossible to completely move away from addressing, as
userspace and the SCSI core need ways to
Luben Tuikov wrote:
Even simpler: the transport layer, calls SCSI Core, saying: Hey here is
a pointer to struct scsi_domain_device. If you want, you an send REPORT
LUNS and other things to it.
For the SG_IO ioctl, /dev/sg and request_queue usage, SCSI core must map
an address (currently
On 08/26/05 15:24, Jeff Garzik wrote:
Luben Tuikov wrote:
Even simpler: the transport layer, calls SCSI Core, saying: Hey here is
a pointer to struct scsi_domain_device. If you want, you an send REPORT
LUNS and other things to it.
For the SG_IO ioctl, /dev/sg and request_queue usage, SCSI
On 08/26/05 14:48, Jeff Garzik wrote:
No host numbers, no routing information. This is all
transparent to SCSI Core, and NONE of its business.
Routing is an essential part of the SCSI core's duties.
[I'm not a big fan of reading mixed-message emails, but what can you do...]
The SCSI core
Luben Tuikov wrote:
On 08/26/05 14:48, Jeff Garzik wrote:
No host numbers, no routing information. This is all
transparent to SCSI Core, and NONE of its business.
Routing is an essential part of the SCSI core's duties.
[I'm not a big fan of reading mixed-message emails, but what can you
Luben Tuikov wrote:
On 08/26/05 15:24, Jeff Garzik wrote:
Luben Tuikov wrote:
Even simpler: the transport layer, calls SCSI Core, saying: Hey here is
a pointer to struct scsi_domain_device. If you want, you an send REPORT
LUNS and other things to it.
For the SG_IO ioctl, /dev/sg and
Stefan Richter wrote:
Luben Tuikov wanted...
to move _away_ from HCIL. So that addressing of devices in SCSI Core
is _completely_ independent of addressing at the protocol layer.
I second that.
A move away from forced HCIL addressing would be a good thing.
However, its impossible to
On Mon, Aug 22, 2005 at 05:08:33PM -0600, Moore, Eric Dean wrote:
On Sunday, August 21, 2005 10:53 AM, Christoph Hellwig wrote:
This is just a brindup helper because the Fusion hardware does a SAS
remote port to target ID mapping in firmware, in fact the firmware
interface only addresses
On Wed, Aug 24, 2005 at 04:05:03PM -0400, Luben Tuikov wrote:
On 08/24/05 13:12, Patrick Mansfield wrote:
On Tue, Aug 23, 2005 at 07:55:37PM -0400, Luben Tuikov wrote:
Where does udev get its label?
You can call any script or program from udev and use the result. There are
And
[EMAIL PROTECTED] wrote:
- There are some real challenges in supporting a udev-named boot
device. For the most part, it's a distro issue, which is becoming
better. PS: for $10, name a 2.6 distro that uses udev out
of the box for disk names and its installation. For $10 more,
can it
Luben Tuikov wrote:
On 08/22/05 00:55, Matt Domsch wrote:
On Sat, Aug 20, 2005 at 12:15:41AM -0400, [EMAIL PROTECTED] wrote:
- There are some real challenges in supporting a udev-named boot
device. For the most part, it's a distro issue, which is becoming
better. PS: for $10, name a 2.6
On Sat, Aug 20, 2005 at 12:15:41AM -0400, [EMAIL PROTECTED] wrote:
- the target id is logical for everything but SPI
For FC, target ids are typically assigned to devices on a
1st-seen-1st-assigned basis. For several reasons, there can be
changes in port discovery order after link events
As others stated, id is already a tag/label. You should be
able to pass
whatever id you want to scsi_scan_target, like the FC ID
(port_id), and
then we also want an abstract iterator in fc transport for the id for
usage in scsi_scan.c:scsi_scan_channel. Then you can lose all the
[EMAIL PROTECTED] wrote:
As others stated, id is already a tag/label. You should be
able to pass
whatever id you want to scsi_scan_target, like the FC ID
(port_id),
[...]
If the port id changes during run time, what are you to do ?
[...]
This approach only works as long as the transport's
I thought by the target id is logical for everything but
SPI you meant
that FC enumerated the scsi_device id.
Yes, I meant that.
I didn't mean to address problems with persistent names, just map the
scsi_device id to an FC value.
True. Port ID is just a bad example. Unfortunately, there's
On 08/23/05 13:28, Stefan Richter wrote:
[EMAIL PROTECTED] wrote:
As others stated, id is already a tag/label. You should be
able to pass
whatever id you want to scsi_scan_target, like the FC ID
(port_id),
[...]
If the port id changes during run time, what are you to do ?
[...]
This
On 08/23/05 11:42, Patrick Mansfield wrote:
On Sat, Aug 20, 2005 at 12:15:41AM -0400, [EMAIL PROTECTED] wrote:
- the target id is logical for everything but SPI
For FC, target ids are typically assigned to devices on a
1st-seen-1st-assigned basis. For several reasons, there can be
changes
On 08/22/05 00:55, Matt Domsch wrote:
On Sat, Aug 20, 2005 at 12:15:41AM -0400, [EMAIL PROTECTED] wrote:
- There are some real challenges in supporting a udev-named boot
device. For the most part, it's a distro issue, which is becoming
better. PS: for $10, name a 2.6 distro that uses udev
On Sat, Aug 20, 2005 at 12:15:41AM -0400, [EMAIL PROTECTED] wrote:
- There are some real challenges in supporting a udev-named boot
device. For the most part, it's a distro issue, which is becoming
better. PS: for $10, name a 2.6 distro that uses udev out
of the box for disk names and
--- Christoph Hellwig [EMAIL PROTECTED] wrote:
For SAS, looking at Christoph's code -
The target id comes from the LLDD.
This is just a brindup helper because the Fusion hardware does a SAS
remote port to target ID mapping in firmware, in fact the firmware
interface only addresses them
On Sat, Aug 20, 2005 at 12:15:41AM -0400, [EMAIL PROTECTED] wrote:
Now - back to Christoph's point
For iSCSI, (correct me if I'm wrong) as the scsi_host is mapped 1:1
with the session, there really is no such thing as multiple targets,
so it works. Even if it isn't 1:1, it is controlled
On Sat, Aug 20, 2005 at 01:34:49PM -0400, Luben Tuikov wrote:
that even if my minimal code goes in now there's absolutely no reason
we can't replace it completely later on. See the evolution of the FC
transport class.
Who makes all those decisions?
In the end James, unless he'd be
On Sat, Aug 20, 2005 at 01:23:04PM -0400, Luben Tuikov wrote:
I don't mind LLDD giving channel and id to SCSI Core. Not at all.
What I mind is the _way_ it is done.
Just consider this (and I'm sure you have the same sentiments):
slave alloc gives you channel and id and lun/2 to find out
On Fri, Aug 19, 2005 at 04:32:15PM -0400, Luben Tuikov wrote:
The current SAS class will only get validated when it actually meets
real SAS topologies, which is acceptable in my view just to get this
project actually moving; code can always be updated later ...
James, the current SAS
On 08/20/05 00:15, [EMAIL PROTECTED] wrote:
Ok, so I guess I owe you a response. I hesitate, as this discussion
always becomes larger than it should.
There are 2 key points:
- the target id is logical for everything but SPI
- following old SPI behavior, users expect the same devices to
On 08/20/05 05:18, Christoph Hellwig wrote:
On Fri, Aug 19, 2005 at 04:32:15PM -0400, Luben Tuikov wrote:
The current SAS class will only get validated when it actually meets
real SAS topologies, which is acceptable in my view just to get this
project actually moving; code can always be updated
On Thu, Aug 18, 2005 at 03:04:01PM -0400, Jeff Garzik wrote:
Depending on how SATA support is implemented, it may be useful for that.
You can already see how SATA support is implemented ;-)
We just need to wrap it in a transport class.
SATA support for SAS host adapters. Especially when
On Thu, Aug 18, 2005 at 04:05:29PM -0400, Luben Tuikov wrote:
On 08/18/05 13:56, Christoph Hellwig wrote:
I was trying to avoid the need for an rport object, but I'm not yet sure
it's feasible. We certainly won't put in target-persistency support
similar to FC, that was just a hack to get
On 08/19/05 10:06, Christoph Hellwig wrote:
SATA support for SAS host adapters. Especially when talking STP to a
bridge this is a little more complicated than the current libata model.
That doesn't mean I don't want to share code and mechanisms but it'll
need a little refactoring at least.
On Fri, Aug 19, 2005 at 01:51:56PM -0400, Luben Tuikov wrote:
On 08/19/05 10:06, Christoph Hellwig wrote:
SATA support for SAS host adapters. Especially when talking STP to a
bridge this is a little more complicated than the current libata model.
That doesn't mean I don't want to share
On 08/19/05 13:54, Christoph Hellwig wrote:
On Fri, Aug 19, 2005 at 01:51:56PM -0400, Luben Tuikov wrote:
On 08/19/05 10:06, Christoph Hellwig wrote:
SATA support for SAS host adapters. Especially when talking STP to a
bridge this is a little more complicated than the current libata model.
On Fri, Aug 19, 2005 at 01:56:39PM -0400, Luben Tuikov wrote:
Yes. But to get that to work we'll need to fix some assumptions in
libata, define proper interfaces between the SAS LLDD, the SAS transport
class and libata. It's doable and desirable, but it'll need some work.
Do you have a
On 08/19/05 13:59, Christoph Hellwig wrote:
Which one is it that will let you do this?
Currently none. Fusion is doing the SATA command translation in firmware.
This is more for Adapters in the style of the Adaptec design where it
would be done in the host software stack.
So you're doing
On 08/19/05 13:59, Christoph Hellwig wrote:
On Fri, Aug 19, 2005 at 01:56:39PM -0400, Luben Tuikov wrote:
Yes. But to get that to work we'll need to fix some assumptions in
libata, define proper interfaces between the SAS LLDD, the SAS transport
class and libata. It's doable and desirable,
On Fri, 2005-08-19 at 14:07 -0400, Luben Tuikov wrote:
So you're doing architectural decisions based on guesses on how
Adaptec's (design) driver is?
You can't have it both ways. We have to take a fully theoretical
approach (which does involve guesswork) because only the vendors have
the actual
On 08/19/05 15:59, James Bottomley wrote:
On Fri, 2005-08-19 at 14:07 -0400, Luben Tuikov wrote:
So you're doing architectural decisions based on guesses on how
Adaptec's (design) driver is?
You can't have it both ways. We have to take a fully theoretical
You just made a decision.
Luben Tuikov wrote:
James, the current SAS class _will_go_ into the kernel because:
- It is 3 vendor driven: LSI, Dell, HP.
- It is being developed by you and Christoph, the people
who decide what goes in or not.
No, not for these reasons.
It will go in because it is small,
This is a heck of a statement... The customers don't see it
as SAS vs FC
vs SPI, they just see it as SCSI, and there's a lot of
expectations on
consistent behavior. We take a lot of heat defending the community's
position, even from companies that you would have thought
had signed on
Christoph,
I like it, and have no real complaints.
As familiar as this looks, there were a couple of conventions in the FC
transport that I thought should have carried over here. Namely, I saw
not all attributes being the same, thus I created 3 categories of
attributes:
Private:
These
Of Smart, James
Sent: Thursday, August 18, 2005 7:58 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
linux-scsi@vger.kernel.org
Subject: RE: [PATCH] minimal SAS transport class
Christoph,
I like it, and have no real complaints
One more thing missing...
As there is a transport object between the scsi_host and scsi_target,
the transport needs to pick up the changes made to deal with scans
made outside of the transport (after a scsi_target has been removed).
The fix that got merged into the scsi-misc tree can be seen at:
I was trying to avoid the need for an rport object, but I'm
not yet sure
it's feasible. We certainly won't put in target-persistency support
similar to FC, that was just a hack to get the existing
drivers migrated
without lots of complaints, it's not going in for new transports like
SAS
On 08/18/05 13:56, Christoph Hellwig wrote:
I was trying to avoid the need for an rport object, but I'm not yet sure
it's feasible. We certainly won't put in target-persistency support
similar to FC, that was just a hack to get the existing drivers migrated
without lots of complaints, it's
On 08/18/05 14:48, [EMAIL PROTECTED] wrote:
This is a heck of a statement... The customers don't see it as SAS vs FC
vs SPI, they just see it as SCSI, and there's a lot of expectations on
consistent behavior. We take a lot of heat defending the community's
position, even from companies that
Good stuff, Christoph!
Luben
--- Christoph Hellwig [EMAIL PROTECTED] wrote:
This is a minmal, bottom-up SAS transport class. So far it only exposed
information about the SAS port/phy and SAS device (scsi target). I hope
this will integrate nicely with the top-down work Luben has done
On Mon, Aug 15, 2005 at 11:13:30AM -0400, Luben Tuikov wrote:
+void sas_add_target(struct sas_port *port, struct sas_identify *attached,
+ uint channel, uint target)
+{
+ if (attached-target_port_protocols
+ (SAS_PROTOCOL_SSP|SAS_PROTOCOL_STP|SAS_PROTOCOL_SATA))
+
60 matches
Mail list logo
