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
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/
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
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
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
[email protected]
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
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
[email protected]
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/
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
[email protected]
Hi,
On Tue, Feb 7, 2012 at 09:28, Chris Boot <[email protected]> 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: [email protected]
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/
On 6 Feb 2012, at 23:00, Julian Calaby wrote:
> Hi,
>
> On Tue, Feb 7, 2012 at 09:28, Chris Boot <[email protected]> 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
[email protected]
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<[email protected]> 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
[email protected]
Tel: 01271 414100
Hi,
On Tue, Feb 7, 2012 at 18:38, Chris Boot <[email protected]> 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<[email protected]> ?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: [email protected]
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/
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<[email protected]> 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/
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
[email protected]