FireWire/SBP2 Target mode

FireWire/SBP2 Target mode

[Chris Boot]

Hi folks,

Now that we have a nice SCSI target framework in the kernel, and drivers 
either in-tree or being worked on for iSCSI, FC, FCoE, SAS and iSER, I 
was wondering about the possibility of adding FireWire to that list. 
Apple Macs have had a FireWire Target Disk mode for a long time, and 
there is even a program called Endpoint[1] that apparently does this on 
Linux though it looks completely untouched since 2003 and no longer 
works as it depends on the old FireWire stack.

I would very much like to see something like this added to the kernel, 
and would very much like to contribute to writing this feature. However 
my kernel development knowledge is very limited indeed so this would 
require a lot hand-holding and mentoring.

What's the interest in such a feature? Would anyone be able to give some 
(a lot?) of their time to help write this?

Thanks,
Chris

[1] http://oss.oracle.com/projects/endpoint/


------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
user administration capabilities and model configuration. Take 
the hassle out of deploying and managing Subversion and the 
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2

Re: FireWire/SBP2 Target mode

[Stefan Richter]

On Aug 17 Chris Boot wrote:
> Now that we have a nice SCSI target framework in the kernel, and drivers 
> either in-tree or being worked on for iSCSI, FC, FCoE, SAS and iSER, I 
> was wondering about the possibility of adding FireWire to that list. 
> Apple Macs have had a FireWire Target Disk mode for a long time, and 

Side note:  This target mode is a feature of their OpenFirmware and EFI
firmwares, not of the Mac OS and the OS X.  Though both firmware- and
operating-system-implemented SBP-2 targets certainly have their use cases.
Aside from the SBP-2 target in Macs and from Oracle Endpoint, I only know
of SBP-2 targets that are built upon dedicated bus bridge silicon.

> there is even a program called Endpoint[1] that apparently does this on 
> Linux though it looks completely untouched since 2003 and no longer 
> works as it depends on the old FireWire stack.

It can be made to work again if it and libraw1394 are slightly extended to
use a different API for Configuration ROM changes.  Or Endpoint could be
ported from libraw1394 to <linux/firewire-cdev.h>.  But then it would of
course not benefit from the generic SCSI target infrastructure, e.g. WRT
administration, backing storage choices, or command set support.

> I would very much like to see something like this added to the kernel, 
> and would very much like to contribute to writing this feature. However 
> my kernel development knowledge is very limited indeed so this would 
> require a lot hand-holding and mentoring.
> 
> What's the interest in such a feature?

People keep asking for it; very infrequently though.

> Would anyone be able to give some (a lot?) of their time to help write
> this?
> 
> Thanks,
> Chris
> 
> [1] http://oss.oracle.com/projects/endpoint/

I for one can answer questions about firewire-core's driver API but do not
have much spare time for more, for the time being.

BTW, a kernelspace SBP-2 target drivers would use several of the FireWire
features that the firewire-net driver uses too.  So the sources of that
driver may be of help where the firewire-core kerneldoc comments are
missing or are not providing the bigger picture.
-- 
Stefan Richter
-=====-==-== =--- =---=
http://arcgraph.de/sr/

Re: FireWire/SBP2 Target mode

[Clemens Ladisch]

Chris Boot wrote:
> Now that we have a nice SCSI target framework in the kernel, and drivers
> either in-tree or being worked on for iSCSI, FC, FCoE, SAS and iSER, I
> was wondering about the possibility of adding FireWire to that list.

As far as I can tell from briefly looking at the framework, this would
require both a fabric module (which is nicely abstracted) and a new
protocol (which doesn't seem to be).

Is there any documentation of how to add a new LIO protocol?

And what is the difference between a protocol and a fabric?


Regards,
Clemens

Re: FireWire/SBP2 Target mode

[Andy Grover]

Sorry to raise this thread from the dead.

Chris Boot wrote Aug 2011-ish:
> I would very much like to see something like this added to the
> kernel, and would very much like to contribute to writing this
> feature. However my kernel development knowledge is very limited
> indeed so this would require a lot hand-holding and mentoring.

If you're still interested, I'd definitely encourage you to work on this
project. Me and others on target-devel would be happy to help with any
target-related advice.

On 08/18/2011 09:19 AM, Clemens Ladisch wrote:
> Chris Boot wrote:
>> Now that we have a nice SCSI target framework in the kernel, and drivers
>> either in-tree or being worked on for iSCSI, FC, FCoE, SAS and iSER, I
>> was wondering about the possibility of adding FireWire to that list.
> 
> As far as I can tell from briefly looking at the framework, this would
> require both a fabric module (which is nicely abstracted) and a new
> protocol (which doesn't seem to be).
> 
> Is there any documentation of how to add a new LIO protocol?
> 
> And what is the difference between a protocol and a fabric?

Right now the documentation is the other fabric modules, alas.

You're saying the sbp2 protocol can theoretically be used other places
besides firewire? I'd say put it all in the fabric module for now.

You can also join irc.oftc.net #storage and ask more questions there.

Regards -- Andy

Re: FireWire/SBP2 Target mode

[Stefan Richter]

On Feb 01 Andy Grover wrote:
> You're saying the sbp2 protocol can theoretically be used other places
> besides firewire? I'd say put it all in the fabric module for now.

While SBP-2 is explicitly specified for IEEE 1394 a.k.a. FireWire only,
it could be used on any bus architecture which implements IEEE 1212
"Control and Status Registers (CSR) Architecture for Microcomputer
Buses".  But IEEE 1394 a.k.a. FireWire is nowadays the only remaining IEEE
1212 implementation, as far as I know.

On the other hand, the transport protocol SBP-2 can be used to encapsulate
various protocols besides SCSI.  A long time ago I heard that there were
SBP-2 printers that weren't SCSI printers, but I may have confused
something.

The current version of the protocol, SBP-3 which extends SBP-2
in an upwards compatible way, has been developed specifically in
order to transport AV/C command sets.  (AV/C is a set of specifications
from the 1394 Trade Association that build on top of IEC 61883 "Consumer
audio/video equipment - Digital interface" and is used for camcorders,
audio interfaces, studio-grade video equipment, TV set top boxes etc.)
But I am not aware of any existing SBP-3 target or SBP-3 initiator which
actually implements AV/C.

So in short,
  - SBP-2/3 is only used on the FireWire bus.
  - Potentially there could be SBP-2/3 targets or initiators that
    implement something else than SCSI.  But stock SBP-2/3 initiator
    drivers of popular OSs are SCSI initiators, and non-SCSI SBP-2/3
    targets are extremely rare or don't exist actually.
-- 
Stefan Richter
-=====-===-- --=- ----=
http://arcgraph.de/sr/

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d

Re: FireWire/SBP2 Target mode

[Boaz Harrosh]

On 02/01/2012 11:41 PM, Stefan Richter wrote:
> On Feb 01 Andy Grover wrote:
>> You're saying the sbp2 protocol can theoretically be used other places
>> besides firewire? I'd say put it all in the fabric module for now.
> 
> While SBP-2 is explicitly specified for IEEE 1394 a.k.a. FireWire only,
> it could be used on any bus architecture which implements IEEE 1212
> "Control and Status Registers (CSR) Architecture for Microcomputer
> Buses".  But IEEE 1394 a.k.a. FireWire is nowadays the only remaining IEEE
> 1212 implementation, as far as I know.
> 
> On the other hand, the transport protocol SBP-2 can be used to encapsulate
> various protocols besides SCSI.  A long time ago I heard that there were
> SBP-2 printers that weren't SCSI printers, but I may have confused
> something.
> 

Hmm Interesting. So what do the other FireWire protocols use, like
networking, DV video, audio? they have yet another encapsulating transport
other than SBP-2? What a mess

> The current version of the protocol, SBP-3 which extends SBP-2
> in an upwards compatible way, has been developed specifically in
> order to transport AV/C command sets.  (AV/C is a set of specifications
> from the 1394 Trade Association that build on top of IEC 61883 "Consumer
> audio/video equipment - Digital interface" and is used for camcorders,
> audio interfaces, studio-grade video equipment, TV set top boxes etc.)
> But I am not aware of any existing SBP-3 target or SBP-3 initiator which
> actually implements AV/C.
> 
> So in short,
>   - SBP-2/3 is only used on the FireWire bus.
>   - Potentially there could be SBP-2/3 targets or initiators that
>     implement something else than SCSI.  But stock SBP-2/3 initiator
>     drivers of popular OSs are SCSI initiators, and non-SCSI SBP-2/3
>     targets are extremely rare or don't exist actually.

Thanks that was informative
I'll have a deeper look

Boaz

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d

Re: FireWire/SBP2 Target mode

[Clemens Ladisch]

Boaz Harrosh wrote:
> [...] So what do the other FireWire protocols use, like networking,
> DV video, audio?

Their own standard or non-standard mechanism.

> they have yet another encapsulating transport other than SBP-2?

These other devices require isochronous or broadcast transfers, which
SBP-2/3 does not handle well or at all.  It might be possible to use
SBP-3 for control commands (which is exactly what SBP-3's AV/C support
is), but using it would not bring any worthwhile benefits over existing
transports, and would just introduce incompatibilities with all previous
soft- and hardware.


Regards,
Clemens

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d

Re: FireWire/SBP2 Target mode

[Chris Boot]

Hi folks,

I've been forging ahead in the last few days with my target code and 
have got to a point where it appears to work fairly well and now needs 
some real testing and ideally some initial review.

So far I've tested that I can export LUNs to Linux and Mac OS X machines 
and they can read/write data without issues as you might expect. I've 
even installed Mac OS X onto an exported LUN and booted from it on an 
old PowerBook without issue.

You can pull the code from:
git://github.com/bootc/Linux-SBP-2-Target.git

Or use GitHub to have a look etc...:
https://github.com/bootc/Linux-SBP-2-Target

I used the following script to set up a LUN on the target:

modprobe firewire-sbp-target
mkdir /sys/kernel/config/target/sbp
mkdir /sys/kernel/config/target/sbp/test
mkdir /sys/kernel/config/target/sbp/test/unit_0
mkdir /sys/kernel/config/target/sbp/test/unit_0/lun/lun_0
ln -s /sys/kernel/config/target/core/iblock_0/test 
/sys/kernel/config/target/sbp/test/unit_0/lun/lun_0/test
echo 1 > /sys/kernel/config/target/sbp/test/unit_0/enable

Please note that you can't then disable a unit until all the targets are 
logged-out. For Linux this usually means 'rmmod firewire_sbp2'. This is 
one of the first things I'd like to fix but I'm not entirely sure how to 
go about it yet.

Thanks,
Chris

-- 
Chris Boot
bootc@bootc.net

Re: FireWire/SBP2 Target mode

[Clemens Ladisch]

Chris Boot wrote:
> You can pull the code from:
> git://github.com/bootc/Linux-SBP-2-Target.git

The TODO file says:
> * Update Juju so we can get the speed in the fw_address_handler callback

What is the speed needed for?

SBP-2 says:
| The target shall issue data transfer requests with a speed equal to
| that specified by the spd field in the ORB.

SBP-3 says:
| The target shall issue data transfer requests with a speed equal to
| that specified by the controlling spd field, whether in the ORB or in
| a node selector in an associated page table.

> Please note that you can't then disable a unit until all the targets
> are logged-out. For Linux this usually means 'rmmod firewire_sbp2'.

That driver should not, by default, log into targets on its own node.


Regards,
Clemens

Re: FireWire/SBP2 Target mode

[Chris Boot]

On 06/02/2012 14:43, Clemens Ladisch wrote:
> Chris Boot wrote:
>> You can pull the code from:
>> git://github.com/bootc/Linux-SBP-2-Target.git
>
> The TODO file says:
>> * Update Juju so we can get the speed in the fw_address_handler callback
>
> What is the speed needed for?

"The speed at which the block write request to the MANAGEMENT_AGENT 
register is received shall determine the speed used by the target for 
all subsequent requests to read the initiator’s configuration ROM, fetch 
ORB’s from initiator memory or store status at the initiator’s 
status_FIFO. Command block ORB’s separately specify the speed for 
requests addressed to the data buffer or page table."

(T10/1155D Revision 4 page 53/54)

> SBP-2 says:
> | The target shall issue data transfer requests with a speed equal to
> | that specified by the spd field in the ORB.
>
> SBP-3 says:
> | The target shall issue data transfer requests with a speed equal to
> | that specified by the controlling spd field, whether in the ORB or in
> | a node selector in an associated page table.

>> Please note that you can't then disable a unit until all the targets
>> are logged-out. For Linux this usually means 'rmmod firewire_sbp2'.
>
> That driver should not, by default, log into targets on its own node.

It still tries to and never appears to give up, so this needs 
blacklisting on the target system until firewire_sbp2 is changed. It's 
harmless other than filling up the kernel log with error messages.

What I meant, however, is if you connect to the target from a separate 
Linux system you will be unable to disable the unit on the target system 
until the _initiator_ logs out. You can do this on the initiator by 
unloading the module, which sends a logout request to the target.

HTH,
Chris

-- 
Chris Boot
bootc@bootc.net

Re: FireWire/SBP2 Target mode

[Stefan Richter]

On Feb 06 Chris Boot wrote:
> On 06/02/2012 14:43, Clemens Ladisch wrote:
> > Chris Boot wrote:
> >> You can pull the code from:
> >> git://github.com/bootc/Linux-SBP-2-Target.git
> >
> > The TODO file says:
> >> * Update Juju so we can get the speed in the fw_address_handler callback
> >
> > What is the speed needed for?
> 
> "The speed at which the block write request to the MANAGEMENT_AGENT 
> register is received shall determine the speed used by the target for 
> all subsequent requests to read the initiator’s configuration ROM, fetch 
> ORB’s from initiator memory or store status at the initiator’s 
> status_FIFO. Command block ORB’s separately specify the speed for 
> requests addressed to the data buffer or page table."
> 
> (T10/1155D Revision 4 page 53/54)

I guess it is not too hard to add this to the AR-req handler.  On the
other hand, I see little reason to follow the SBP-2 spec to the letter
here.  The target driver could just use the maximum speed that the core
figured out.  On the other hand, this requires of course
  - the target to wait for core to finish scanning an initiator,
  - the core to offer an API to look up an fw_device by a
    card--generation--nodeID tuple.

The intention of the spec is IMO clearly to enable target implementations
that do not need to implement topology scanning.  I have a hard time to
think of a valid scenario where an initiator needs to be able to steer a
target towards a lower wire speed than what the participating links and
PHYs actually support.

> > SBP-2 says:
> > | The target shall issue data transfer requests with a speed equal to
> > | that specified by the spd field in the ORB.
> >
> > SBP-3 says:
> > | The target shall issue data transfer requests with a speed equal to
> > | that specified by the controlling spd field, whether in the ORB or in
> > | a node selector in an associated page table.

Clemens, the speed used in data transfers can be different from the speed
to be used to read the initiator's Config ROM/ fetch ORBs/ write status,
because data buffers and page tables can reside on a third node.  (In
practice they reside always on the initiator node, but per spec they
don't have to.)

Again, IMO the target driver could ignore this other speed too and just
use the speed which firewire-core figured out.  But on the other hand,
this would require an fw_device lookup, given card--generation--nodeID; so
using the speed code given in the ORB is much simpler.

Side note:  Like with the speed, the max_payload given in the ORB may be
different from that in the initiator's bus information block, simply
because the data buffers and page tables may reside on a third node with a
different packet payload limit.  Again, just using the max_payload given
in the ORB makes for the easiest implementation (and follows the spec to
the letter).

> >> Please note that you can't then disable a unit until all the targets
> >> are logged-out. For Linux this usually means 'rmmod firewire_sbp2'.
> >
> > That driver should not, by default, log into targets on its own node.
> 
> It still tries to and never appears to give up, so this needs 
> blacklisting on the target system until firewire_sbp2 is changed. It's 
> harmless other than filling up the kernel log with error messages.
> 
> What I meant, however, is if you connect to the target from a separate 
> Linux system you will be unable to disable the unit on the target system 
> until the _initiator_ logs out. You can do this on the initiator by 
> unloading the module, which sends a logout request to the target.

Another way to log out is
# echo "fw4.0" > /sys/bus/firewire/drivers/*sbp2/unbind

(I will post a patch soon which renames this directory from sbp2 to
firewire_sbp2, as a side effect of a logging related change.)
-- 
Stefan Richter
-=====-===-- --=- --==-
http://arcgraph.de/sr/

Re: FireWire/SBP2 Target mode

[Chris Boot]

On 6 Feb 2012, at 20:26, Stefan Richter wrote:

> On Feb 06 Chris Boot wrote:
>> On 06/02/2012 14:43, Clemens Ladisch wrote:
>>> Chris Boot wrote:
>>>> You can pull the code from:
>>>> git://github.com/bootc/Linux-SBP-2-Target.git
>>> 
>>> The TODO file says:
>>>> * Update Juju so we can get the speed in the fw_address_handler callback
>>> 
>>> What is the speed needed for?
>> 
>> "The speed at which the block write request to the MANAGEMENT_AGENT 
>> register is received shall determine the speed used by the target for 
>> all subsequent requests to read the initiator’s configuration ROM, fetch 
>> ORB’s from initiator memory or store status at the initiator’s 
>> status_FIFO. Command block ORB’s separately specify the speed for 
>> requests addressed to the data buffer or page table."
>> 
>> (T10/1155D Revision 4 page 53/54)
> 
> I guess it is not too hard to add this to the AR-req handler.  On the
> other hand, I see little reason to follow the SBP-2 spec to the letter
> here.  The target driver could just use the maximum speed that the core
> figured out.  On the other hand, this requires of course
>  - the target to wait for core to finish scanning an initiator,
>  - the core to offer an API to look up an fw_device by a
>    card--generation--nodeID tuple.
> 
> The intention of the spec is IMO clearly to enable target implementations
> that do not need to implement topology scanning.  I have a hard time to
> think of a valid scenario where an initiator needs to be able to steer a
> target towards a lower wire speed than what the participating links and
> PHYs actually support.

The only thing stopping me from getting the speed is the fact that struct fw_request is opaque. The value is easily available from request->response.speed and I kind of do that already in a very hackish way. I've sent a separate patch which adds a function that can be used to access that one value.

Waiting until the bus scan is complete isn't actually that great as I see the first LOGIN requests often before the fw_node is seen at all. I'd have to turn away the requester and hope they try again. I'm fairly sure my little tweak in my patch is a simple enough solution.

>>> SBP-2 says:
>>> | The target shall issue data transfer requests with a speed equal to
>>> | that specified by the spd field in the ORB.
>>> 
>>> SBP-3 says:
>>> | The target shall issue data transfer requests with a speed equal to
>>> | that specified by the controlling spd field, whether in the ORB or in
>>> | a node selector in an associated page table.
> 
> Clemens, the speed used in data transfers can be different from the speed
> to be used to read the initiator's Config ROM/ fetch ORBs/ write status,
> because data buffers and page tables can reside on a third node.  (In
> practice they reside always on the initiator node, but per spec they
> don't have to.)
> 
> Again, IMO the target driver could ignore this other speed too and just
> use the speed which firewire-core figured out.  But on the other hand,
> this would require an fw_device lookup, given card--generation--nodeID; so
> using the speed code given in the ORB is much simpler.
> 
> Side note:  Like with the speed, the max_payload given in the ORB may be
> different from that in the initiator's bus information block, simply
> because the data buffers and page tables may reside on a third node with a
> different packet payload limit.  Again, just using the max_payload given
> in the ORB makes for the easiest implementation (and follows the spec to
> the letter).

Hmm yes so far I've ignored the fact that the data and page tables can be on a different node. I should add that to the TODO fairly low down :-)

>>>> Please note that you can't then disable a unit until all the targets
>>>> are logged-out. For Linux this usually means 'rmmod firewire_sbp2'.
>>> 
>>> That driver should not, by default, log into targets on its own node.
>> 
>> It still tries to and never appears to give up, so this needs 
>> blacklisting on the target system until firewire_sbp2 is changed. It's 
>> harmless other than filling up the kernel log with error messages.
>> 
>> What I meant, however, is if you connect to the target from a separate 
>> Linux system you will be unable to disable the unit on the target system 
>> until the _initiator_ logs out. You can do this on the initiator by 
>> unloading the module, which sends a logout request to the target.
> 
> Another way to log out is
> # echo "fw4.0" > /sys/bus/firewire/drivers/*sbp2/unbind
> 
> (I will post a patch soon which renames this directory from sbp2 to
> firewire_sbp2, as a side effect of a logging related change.)

Good to know, thanks!

HTH,
Chris

-- 
Chris Boot
bootc@bootc.net

Re: FireWire/SBP2 Target mode

[Julian Calaby]

Hi,

On Tue, Feb 7, 2012 at 09:28, Chris Boot <bootc@bootc.net> wrote:
> On 6 Feb 2012, at 20:26, Stefan Richter wrote:
>
>> On Feb 06 Chris Boot wrote:
>>> On 06/02/2012 14:43, Clemens Ladisch wrote:
>>>> Chris Boot wrote:
>>>>> You can pull the code from:
>>>>> git://github.com/bootc/Linux-SBP-2-Target.git
>>>>
>>>> The TODO file says:
>>>>> * Update Juju so we can get the speed in the fw_address_handler callback
>>>>
>>>> What is the speed needed for?
>>>
>>> "The speed at which the block write request to the MANAGEMENT_AGENT
>>> register is received shall determine the speed used by the target for
>>> all subsequent requests to read the initiator’s configuration ROM, fetch
>>> ORB’s from initiator memory or store status at the initiator’s
>>> status_FIFO. Command block ORB’s separately specify the speed for
>>> requests addressed to the data buffer or page table."
>>>
>>> (T10/1155D Revision 4 page 53/54)
>>
>> I guess it is not too hard to add this to the AR-req handler.  On the
>> other hand, I see little reason to follow the SBP-2 spec to the letter
>> here.  The target driver could just use the maximum speed that the core
>> figured out.  On the other hand, this requires of course
>>  - the target to wait for core to finish scanning an initiator,
>>  - the core to offer an API to look up an fw_device by a
>>    card--generation--nodeID tuple.
>>
>> The intention of the spec is IMO clearly to enable target implementations
>> that do not need to implement topology scanning.  I have a hard time to
>> think of a valid scenario where an initiator needs to be able to steer a
>> target towards a lower wire speed than what the participating links and
>> PHYs actually support.
>
> The only thing stopping me from getting the speed is the fact that struct fw_request is opaque. The value is easily available from request->response.speed and I kind of do that already in a very hackish way. I've sent a separate patch which adds a function that can be used to access that one value.
>
> Waiting until the bus scan is complete isn't actually that great as I see the first LOGIN requests often before the fw_node is seen at all. I'd have to turn away the requester and hope they try again. I'm fairly sure my little tweak in my patch is a simple enough solution.

Stupid question: Could you use a completion queue or something
equivalent to wait until you have seen the fw_node, *then* process the
LOGIN request?

Thanks,

-- 
Julian Calaby

Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/

Re: FireWire/SBP2 Target mode

[Chris Boot]

On 6 Feb 2012, at 23:00, Julian Calaby wrote:

> Hi,
> 
> On Tue, Feb 7, 2012 at 09:28, Chris Boot <bootc@bootc.net> wrote:
>> On 6 Feb 2012, at 20:26, Stefan Richter wrote:
>> 
>>> On Feb 06 Chris Boot wrote:
>>>> On 06/02/2012 14:43, Clemens Ladisch wrote:
>>>>> Chris Boot wrote:
>>>>>> You can pull the code from:
>>>>>> git://github.com/bootc/Linux-SBP-2-Target.git
>>>>> 
>>>>> The TODO file says:
>>>>>> * Update Juju so we can get the speed in the fw_address_handler callback
>>>>> 
>>>>> What is the speed needed for?
>>>> 
>>>> "The speed at which the block write request to the MANAGEMENT_AGENT
>>>> register is received shall determine the speed used by the target for
>>>> all subsequent requests to read the initiator’s configuration ROM, fetch
>>>> ORB’s from initiator memory or store status at the initiator’s
>>>> status_FIFO. Command block ORB’s separately specify the speed for
>>>> requests addressed to the data buffer or page table."
>>>> 
>>>> (T10/1155D Revision 4 page 53/54)
>>> 
>>> I guess it is not too hard to add this to the AR-req handler.  On the
>>> other hand, I see little reason to follow the SBP-2 spec to the letter
>>> here.  The target driver could just use the maximum speed that the core
>>> figured out.  On the other hand, this requires of course
>>>  - the target to wait for core to finish scanning an initiator,
>>>  - the core to offer an API to look up an fw_device by a
>>>    card--generation--nodeID tuple.
>>> 
>>> The intention of the spec is IMO clearly to enable target implementations
>>> that do not need to implement topology scanning.  I have a hard time to
>>> think of a valid scenario where an initiator needs to be able to steer a
>>> target towards a lower wire speed than what the participating links and
>>> PHYs actually support.
>> 
>> The only thing stopping me from getting the speed is the fact that struct fw_request is opaque. The value is easily available from request->response.speed and I kind of do that already in a very hackish way. I've sent a separate patch which adds a function that can be used to access that one value.
>> 
>> Waiting until the bus scan is complete isn't actually that great as I see the first LOGIN requests often before the fw_node is seen at all. I'd have to turn away the requester and hope they try again. I'm fairly sure my little tweak in my patch is a simple enough solution.
> 
> Stupid question: Could you use a completion queue or something
> equivalent to wait until you have seen the fw_node, *then* process the
> LOGIN request?

The fw_address_handler callback is called in interrupt context, and I can't sleep from within there. As far as I'm aware I must call fw_send_response() from within the callback and can't defer that until I've scheduled something on a work queue. Please correct me if I'm wrong though, as that might be useful anyway.

Chris

-- 
Chris Boot
bootc@bootc.net

Re: FireWire/SBP2 Target mode

[Chris Boot]

On 06/02/2012 23:09, Chris Boot wrote:
>
> On 6 Feb 2012, at 23:00, Julian Calaby wrote:
>
>> Hi,
>>
>> On Tue, Feb 7, 2012 at 09:28, Chris Boot<bootc@bootc.net>  wrote:
>>> On 6 Feb 2012, at 20:26, Stefan Richter wrote:
>>>
>>>> On Feb 06 Chris Boot wrote:
>>>>> On 06/02/2012 14:43, Clemens Ladisch wrote:
>>>>>> Chris Boot wrote:
>>>>>>> You can pull the code from:
>>>>>>> git://github.com/bootc/Linux-SBP-2-Target.git
>>>>>>
>>>>>> The TODO file says:
>>>>>>> * Update Juju so we can get the speed in the fw_address_handler callback
>>>>>>
>>>>>> What is the speed needed for?
>>>>>
>>>>> "The speed at which the block write request to the MANAGEMENT_AGENT
>>>>> register is received shall determine the speed used by the target for
>>>>> all subsequent requests to read the initiator’s configuration ROM, fetch
>>>>> ORB’s from initiator memory or store status at the initiator’s
>>>>> status_FIFO. Command block ORB’s separately specify the speed for
>>>>> requests addressed to the data buffer or page table."
>>>>>
>>>>> (T10/1155D Revision 4 page 53/54)
>>>>
>>>> I guess it is not too hard to add this to the AR-req handler.  On the
>>>> other hand, I see little reason to follow the SBP-2 spec to the letter
>>>> here.  The target driver could just use the maximum speed that the core
>>>> figured out.  On the other hand, this requires of course
>>>>   - the target to wait for core to finish scanning an initiator,
>>>>   - the core to offer an API to look up an fw_device by a
>>>>     card--generation--nodeID tuple.
>>>>
>>>> The intention of the spec is IMO clearly to enable target implementations
>>>> that do not need to implement topology scanning.  I have a hard time to
>>>> think of a valid scenario where an initiator needs to be able to steer a
>>>> target towards a lower wire speed than what the participating links and
>>>> PHYs actually support.
>>>
>>> The only thing stopping me from getting the speed is the fact that struct fw_request is opaque. The value is easily available from request->response.speed and I kind of do that already in a very hackish way. I've sent a separate patch which adds a function that can be used to access that one value.
>>>
>>> Waiting until the bus scan is complete isn't actually that great as I see the first LOGIN requests often before the fw_node is seen at all. I'd have to turn away the requester and hope they try again. I'm fairly sure my little tweak in my patch is a simple enough solution.
>>
>> Stupid question: Could you use a completion queue or something
>> equivalent to wait until you have seen the fw_node, *then* process the
>> LOGIN request?
>
> The fw_address_handler callback is called in interrupt context, and I can't sleep from within there. As far as I'm aware I must call fw_send_response() from within the callback and can't defer that until I've scheduled something on a work queue. Please correct me if I'm wrong though, as that might be useful anyway.

Hmm sorry I've thought about this overnight and clearly I was talking 
rubbish. Yes, I need to reply in the fw_address_handler but all I tend 
to do in there is schedule a task to the the main part of the work 
anyway. As most of the operations require fetching an ORB from the 
initiator I have to do this from user context.

So it's possible I could do this by waiting in my scheduled work 
function until the fw_node is available and get the speed from that - 
but that seems like an inordinate amount of work when I can follow the 
standard and do it really easily by pulling it out of the fw_request.

Chris

-- 
Chris Boot
bootc@bootc.net
Tel: 01271 414100

Re: FireWire/SBP2 Target mode

[Julian Calaby]

Hi,

On Tue, Feb 7, 2012 at 18:38, Chris Boot <bootc@bootc.net> wrote:
> On 06/02/2012 23:09, Chris Boot wrote:
>>
>>
>> On 6 Feb 2012, at 23:00, Julian Calaby wrote:
>>
>>> Hi,
>>>
>>> On Tue, Feb 7, 2012 at 09:28, Chris Boot<bootc@bootc.net>  wrote:
>>>>
>>>> On 6 Feb 2012, at 20:26, Stefan Richter wrote:
>>>>
>>>>> On Feb 06 Chris Boot wrote:
>>>>>>
>>>>>> On 06/02/2012 14:43, Clemens Ladisch wrote:
>>>>>>>
>>>>>>> Chris Boot wrote:
>>>>>>>>
>>>>>>>> You can pull the code from:
>>>>>>>> git://github.com/bootc/Linux-SBP-2-Target.git
>>>>>>>
>>>>>>>
>>>>>>> The TODO file says:
>>>>>>>>
>>>>>>>> * Update Juju so we can get the speed in the fw_address_handler
>>>>>>>> callback
>>>>>>>
>>>>>>>
>>>>>>> What is the speed needed for?
>>>>>>
>>>>>>
>>>>>> "The speed at which the block write request to the MANAGEMENT_AGENT
>>>>>> register is received shall determine the speed used by the target for
>>>>>> all subsequent requests to read the initiator’s configuration ROM,
>>>>>> fetch
>>>>>> ORB’s from initiator memory or store status at the initiator’s
>>>>>> status_FIFO. Command block ORB’s separately specify the speed for
>>>>>> requests addressed to the data buffer or page table."
>>>>>>
>>>>>> (T10/1155D Revision 4 page 53/54)
>>>>>
>>>>>
>>>>> I guess it is not too hard to add this to the AR-req handler.  On the
>>>>> other hand, I see little reason to follow the SBP-2 spec to the letter
>>>>> here.  The target driver could just use the maximum speed that the core
>>>>> figured out.  On the other hand, this requires of course
>>>>>  - the target to wait for core to finish scanning an initiator,
>>>>>  - the core to offer an API to look up an fw_device by a
>>>>>    card--generation--nodeID tuple.
>>>>>
>>>>> The intention of the spec is IMO clearly to enable target
>>>>> implementations
>>>>> that do not need to implement topology scanning.  I have a hard time to
>>>>> think of a valid scenario where an initiator needs to be able to steer
>>>>> a
>>>>> target towards a lower wire speed than what the participating links and
>>>>> PHYs actually support.
>>>>
>>>>
>>>> The only thing stopping me from getting the speed is the fact that
>>>> struct fw_request is opaque. The value is easily available from
>>>> request->response.speed and I kind of do that already in a very hackish way.
>>>> I've sent a separate patch which adds a function that can be used to access
>>>> that one value.
>>>>
>>>> Waiting until the bus scan is complete isn't actually that great as I
>>>> see the first LOGIN requests often before the fw_node is seen at all. I'd
>>>> have to turn away the requester and hope they try again. I'm fairly sure my
>>>> little tweak in my patch is a simple enough solution.
>>>
>>>
>>> Stupid question: Could you use a completion queue or something
>>> equivalent to wait until you have seen the fw_node, *then* process the
>>> LOGIN request?
>>
>>
>> The fw_address_handler callback is called in interrupt context, and I
>> can't sleep from within there. As far as I'm aware I must call
>> fw_send_response() from within the callback and can't defer that until I've
>> scheduled something on a work queue. Please correct me if I'm wrong though,
>> as that might be useful anyway.
>
>
> Hmm sorry I've thought about this overnight and clearly I was talking
> rubbish. Yes, I need to reply in the fw_address_handler but all I tend to do
> in there is schedule a task to the the main part of the work anyway. As most
> of the operations require fetching an ORB from the initiator I have to do
> this from user context.
>
> So it's possible I could do this by waiting in my scheduled work function
> until the fw_node is available and get the speed from that - but that seems
> like an inordinate amount of work when I can follow the standard and do it
> really easily by pulling it out of the fw_request.

Fair enough, I assumed that there might have been some reason why you
wouldn't have it at that point, not just convention getting in the
way.

Thanks,

-- 
Julian Calaby

Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/

Re: FireWire/SBP2 Target mode

[Stefan Richter]

On Feb 07 Chris Boot wrote:
> On 06/02/2012 23:09, Chris Boot wrote:
> > On 6 Feb 2012, at 23:00, Julian Calaby wrote:
> >> On Tue, Feb 7, 2012 at 09:28, Chris Boot<bootc@bootc.net>  wrote:
> >>> Waiting until the bus scan is complete isn't actually that great
> >>> as I see the first LOGIN requests often before the fw_node is seen
> >>> at all. I'd have to turn away the requester and hope they try again.

An SBP-2 initiator should be prepared to retry its first login attempt if
it sent it shortly after a bus reset.  The target may still hold
reservations for previously loggend in initiators for up to reconnect_hold
+ 2 seconds after bus reset.

> >>> I'm fairly sure my little tweak in my patch is a simple enough
> >>> solution.

Yep.

> >> Stupid question: Could you use a completion queue or something
> >> equivalent to wait until you have seen the fw_node, *then* process the
> >> LOGIN request?
> >
> > The fw_address_handler callback is called in interrupt context, and
> > I can't sleep from within there. As far as I'm aware I must call
> > fw_send_response() from within the callback and can't defer that until
> > I've scheduled something on a work queue. Please correct me if I'm
> > wrong though, as that might be useful anyway.
> 
> Hmm sorry I've thought about this overnight and clearly I was talking 
> rubbish. Yes, I need to reply in the fw_address_handler but all I tend 
> to do in there is schedule a task to the the main part of the work 
> anyway. As most of the operations require fetching an ORB from the 
> initiator I have to do this from user context.

Technically there are two things to perform:

 1. Finish the inbound IEEE 1394 transaction to the management agent
    register by means of fw_send_response().  As far as I can tell, you
    don't have to do that in the address_callback().  But there is little
    reason not to.

    fw_send_response() ends the lifetime of an fw_request, so read the
    speed code before you respond.

 2. Finish the inbound SBP-2 transaction; here the login.  This and
    everything that leads up to it is definitely easiest to implement in
    a process context, e.g. workqueue item.
-- 
Stefan Richter
-=====-===-- --=- --===
http://arcgraph.de/sr/

Re: FireWire/SBP2 Target mode

[Chris Boot]

On 07/02/2012 19:17, Stefan Richter wrote:
> On Feb 07 Chris Boot wrote:
>> On 06/02/2012 23:09, Chris Boot wrote:
>>> On 6 Feb 2012, at 23:00, Julian Calaby wrote:
>>>> Stupid question: Could you use a completion queue or something
>>>> equivalent to wait until you have seen the fw_node, *then* process the
>>>> LOGIN request?
>>>
>>> The fw_address_handler callback is called in interrupt context, and
>>> I can't sleep from within there. As far as I'm aware I must call
>>> fw_send_response() from within the callback and can't defer that until
>>> I've scheduled something on a work queue. Please correct me if I'm
>>> wrong though, as that might be useful anyway.
>>
>> Hmm sorry I've thought about this overnight and clearly I was talking
>> rubbish. Yes, I need to reply in the fw_address_handler but all I tend
>> to do in there is schedule a task to the the main part of the work
>> anyway. As most of the operations require fetching an ORB from the
>> initiator I have to do this from user context.
>
> Technically there are two things to perform:
>
>   1. Finish the inbound IEEE 1394 transaction to the management agent
>      register by means of fw_send_response().  As far as I can tell, you
>      don't have to do that in the address_callback().  But there is little
>      reason not to.
>
>      fw_send_response() ends the lifetime of an fw_request, so read the
>      speed code before you respond.
>
>   2. Finish the inbound SBP-2 transaction; here the login.  This and
>      everything that leads up to it is definitely easiest to implement in
>      a process context, e.g. workqueue item.

Yep I do exactly that - I save the speed then schedule_work() inside the 
address callback, then call fw_send_response() still within the 
callback. The work callback uses fw_run_transaction() to fetch the ORB 
and deal with it.

Cheers,
Chris

-- 
Chris Boot
bootc@bootc.net