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, cle
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 mig
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 ma
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
> > kno
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
On Fri, Aug 26, 2005 at 11:47:22AM -0400, Luben Tuikov wrote:
> Do you think it would be beneficial to revisit struct
> scsi_target to something like struct scsi_domain_device and
> have a kobject in it. Then the FC/SAS/iSCSI/USB layer upon finding
> a domain device, they call a suitable function
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/
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
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
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
>
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, la
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 bon
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 re
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 d
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
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
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 HCI
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 r
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 route CDBs
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
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
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
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 com
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.
--
Stefan Richter
-=-=-=-= =--- ==--=
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscri
On 08/24/05 16:42, Patrick Mansfield wrote:
>>And where does _it_ get it?
>
>
> You can write a program to supply it :)
Some of those would depend on the transport and I'd like
_transport_ things to "die" at _transport_ layer.
The transport layer would add as much as possible, then
SCSI Core, t
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
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 _my_ business,
> what is done with or to t
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 addres
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
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
On 08/22/05 17:53, Mike Anderson wrote:
> Luben Tuikov <[EMAIL PROTECTED]> wrote:
>
>>Yes, that's cool.
>>
>>How about specifying the LU label _and_ the FS label to "root="?
>>
>>root=[:]
>>
>> :=
>> WWN,
>> HCIL,
>> Funky name 1,
>> Funky name 2.
>>
>> :=
>> filesystem sp
> 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, t
On Tue, Aug 23, 2005 at 12:16:45PM -0400, [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), and
> > then we also want an abstract iterator in fc transport for the id
[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 id
> 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
> fc_
On Tue, Aug 23, 2005 at 08:42:32AM -0700, Patrick Mansfield 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), and
> then we also want an abstract iterator in fc transport for the id for
> usage in s
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 (
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
[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
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 them using this assigned ID, which is a big
> shortcoming in the Fusio
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
Luben Tuikov <[EMAIL PROTECTED]> wrote:
> Yes, that's cool.
>
> How about specifying the LU label _and_ the FS label to "root="?
>
> root=[:]
>
> :=
> WWN,
> HCIL,
> Funky name 1,
> Funky name 2.
>
> :=
> filesystem specific label.
>
> All those labels are
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
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 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 b
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 control
--- 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 address
>
> > 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?
>
> More generally, why is SCSI Core not being managed by
> Documentation/ManagingStyle?
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
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 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
[EMAIL PROTECTED] wrote:
For SAS, looking at Christoph's code -
The target id comes from the LLDD. So either the LLDD maintains a
map of SAS port addresses to target ids, or the mapping could change,
same as FC. Christoph's argument is that FC's issue was historical.
As James and I discussed
> > 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
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, a
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
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 actua
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 des
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 doi
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
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 libat
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 sha
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 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 t
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. Especiall
On Thu, Aug 18, 2005 at 02:48:50PM -0400, [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, e
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 t
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
[EMAIL PROTECTED] wrote:
What we might need an rport for is to support SMP. I'm
not yet sure how to do SMP passthrough, but we will need some object
to represent SMP ports.
Depending on how SATA support is implemented, it may be useful for that.
You can already see how SATA support is impl
> 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
On Thu, Aug 18, 2005 at 10:02:21AM -0400, [EMAIL PROTECTED] wrote:
> In tracking how you were using the patch, it highlighted that you
> were skipping a step. The api is such that it does not expect remote
> SAS ports to be instantiated. They should have be (just like FC).
> Your api is written
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:
From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf 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 SA
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 are
On 08/15/05 11:21, Christoph Hellwig wrote:
> 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 &
>>>+(SA
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_SA
> +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))
> + scsi_scan_target(&port->dev, channel, target,
On 08/15/05 10:35, Arjan van de Ven wrote:
> On Mon, 2005-08-15 at 15:55 +0200, Christoph Hellwig wrote:
>
>>+EXPORT_SYMBOL(sas_add_target);
>
>
> should these exports be _GPL? After all they're very much linux specific
> functionality...
Someone needs this for a binary only driver? ;-)
On Mon, 2005-08-15 at 15:55 +0200, Christoph Hellwig wrote:
> +EXPORT_SYMBOL(sas_add_target);
should these exports be _GPL? After all they're very much linux specific
functionality...
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROT
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 d
79 matches
Mail list logo
