rtnet-developers — development-related list

Re: [RTnet-developers] progress in real-time firewire project

[Jan K. <ki...@rt...>]

Zhang Yuchen wrote:
> Hi, 
> last week, I delved into the current firewire linux drivers, ie.,
> ohci1394+ieee1394. Then I realized the biggest non-real-time point here is
> the "task handover" between interrupt handler and the corresponding tasklet
> for the events, like a received packet.The handover is done in the way of
> "Bottomhalf", which is not considered to be real-time safe.  Both of the
> interrupt handler and the tasklets are defined and registered in ohci1394.
> The function hpsb_xxx, which is defined in ieee1394, for offering services
> to the various high-level applications, is invoked in the tasklets of
> ohci1394. There can be minimally 4 tasklets, respectively for 4 contexts: at
> (asynchronous transmission) request, at response, ar(asynchronous reception)
> request and ar response. When isochronous transaction is required, there
> will be more.  But the demuliplexing is done by hardware. In interrupt
> handler, the software reads the register of the hardware to get the context.

This sounds very interesting!

I think, for mapping Firewire on the Ethernet model (as a first step at 
least), only the asynchronous contexts are relevant. How do these 
request/response handshakes work? What is the difference to the xmit 
handlers of Ethernet drivers and their reception interrupt handlers? 
When I want to transmit a packet via Firewire, what steps has to be 
performed in software? On the other side, how much demultiplexing is 
done by the hardware on reception? MAC addresses, or also some higher 
layer addresses? How does the data path look like in that case?

In other words, what happens in-between:

at request  -
at response -    ?    - transmit payload to node X
ar request  -    ?    - receive payload from node Y
ar response -


Whenever you may find out some more details about the programming model 
of isochronous data, this would be interesting for future improvements.
Scenario A: Node 1 sends its sensor data regularly to Node 2-4.
Scenario B: All nodes exchanges their input data and output commands on 
a regular basis.
Scenario C: Application A on node 1 transmits its data every 10 ms to 
application B on node 2, application C on node 3 does the same to 
application D also on node 2.

Could those scenarios easily be mapped on isochronouse Firewire? On 
which abstraction level can the streams be multiplexed and demultiplexed?

> To change the bottomhalf handover, the stack manager mechanism seems to be
> usable.One option is to build a separate stack_manager for firewire, another
> is to arrange a new route for firewire in current stack_manager, which could
> be totally different from the other routes for ethernet. I would like to
> have your suggestions or questions for this.  

Cannot give you an advice yet as I do not fully understand the data 
paths. The job of the stack manager is to demultiplex the protocol type 
and forward the incoming packet to the respective protocol handler (IP, 
RTmac, user-defined protocols, ...). Do you have to do some work before 
this step for Firewire? Or what do you mean with different routes?

Generally, using two stack managers may be useful if you want to 
prioritise one over the other. Otherwise, having two tasks will likely 
only increase the overhead for handling incoming packets. A simple 
differentiation upon rtskb dequeuing which type of packet need special 
preparation (i.e. Firewire) should be more efficient. At some point, 
both the Ethernet and the Firewire path should become one again, at 
least for asynchronous traffic and in case there is no advanced 
high-layer hardware demultiplexing available.

> 
> Currently I lack the knowledge of rtai to understand the internal working of
> stack_manager. A simple questions is: when the "do_stacktask" of
> stack_manager is woke up and start running, will it be scheduled away from
> CPU, not because of the semaphore? Or will it be preempted by other
> real-time task? 
> 

The stack manager is by default running at the highest but one priority 
in the system (the TDMA output task has the highest one in a standard 
setup). Therefore, it is normally not interrupted. It's task is to find 
the recipient of a packet - either a user task, an internal service task 
(RTcfg), or some important handler running inside the stack manager's 
context (callback handlers, RTmac/TDMA, etc.). The stack manager is 
trigger by the signal of a driver which just placed a new packet inside 
the manager's queue. You may say, the stack manager is a heavy-weighted 
tasklet ;).

Jan

[RTnet-developers] progress in real-time firewire project

[Zhang Y. <y.z...@st...>]

Hi, 
last week, I delved into the current firewire linux drivers, ie.,
ohci1394+ieee1394. Then I realized the biggest non-real-time point here is
the "task handover" between interrupt handler and the corresponding tasklet
for the events, like a received packet.The handover is done in the way of
"Bottomhalf", which is not considered to be real-time safe.  Both of the
interrupt handler and the tasklets are defined and registered in ohci1394.
The function hpsb_xxx, which is defined in ieee1394, for offering services
to the various high-level applications, is invoked in the tasklets of
ohci1394. There can be minimally 4 tasklets, respectively for 4 contexts: at
(asynchronous transmission) request, at response, ar(asynchronous reception)
request and ar response. When isochronous transaction is required, there
will be more.  But the demuliplexing is done by hardware. In interrupt
handler, the software reads the register of the hardware to get the context.

To change the bottomhalf handover, the stack manager mechanism seems to be
usable.One option is to build a separate stack_manager for firewire, another
is to arrange a new route for firewire in current stack_manager, which could
be totally different from the other routes for ethernet. I would like to
have your suggestions or questions for this.  

Currently I lack the knowledge of rtai to understand the internal working of
stack_manager. A simple questions is: when the "do_stacktask" of
stack_manager is woke up and start running, will it be scheduled away from
CPU, not because of the semaphore? Or will it be preempted by other
real-time task? 

Looking forward to your reply. 
 
Regards,
Zhang Yuchen
MSc Student
Control Engineering Group
University of Twente
The Netherlands
 

[RTnet-developers] Re: [RTnet-users] about "context" in rtdm

[Jan K. <ki...@rt...>]

Zhang Yuchen wrote:

>Thx. Now I am more clear about the "context". 
> 
>This afternoon, I tried out with the round_trip_time test, without loading the 
>modules: rtmac and rtcfg, but it didn't work.(The showtime simply get stuck, 
>and did not show anyth) Do I need these modules to run this test?  
>  
>
If you don't use RTcfg you have to resolve the host routes manually 
using "rtroute solicit ...". Likely, this caused your problems.

>If I understand it correctly, rtmac and rtcfg are just two entries registered 
>in the "rt_packets" of stack manager, as ipv4 does. So it is possible to 
>communicate directly via ipv4, without any MAC from rtmac or distrib. 
>configuration from rtcfg, right? Then, shall the round_trip_time test be able 
>to run with only rtnet module and network card driver.  
>  
>
Yes, RTmac and RTcfg are optional if you can live without their features.

> 
>I remeber last time I tried out with the round_trip_time test, it did work. 
>But I used the script "rtnet", so all the modules were loaded.   
>  
>
...and all routes were resolved :)

Jan

[RTnet-developers] Re: [RTnet-users] about "context" in rtdm

[Zhang Y. <S00...@st...>]

Thx. Now I am more clear about the "context". 
 
This afternoon, I tried out with the round_trip_time test, without loading the 
modules: rtmac and rtcfg, but it didn't work.(The showtime simply get stuck, 
and did not show anyth) Do I need these modules to run this test? 
 
If I understand it correctly, rtmac and rtcfg are just two entries registered 
in the "rt_packets" of stack manager, as ipv4 does. So it is possible to 
communicate directly via ipv4, without any MAC from rtmac or distrib. 
configuration from rtcfg, right? Then, shall the round_trip_time test be able 
to run with only rtnet module and network card driver.  
 
I remeber last time I tried out with the round_trip_time test, it did work. 
But I used the script "rtnet", so all the modules were loaded.  
 
Could you please give me some hints about this?    
 
Thx in adv.  
--  
Zhang Yuchen  MSc. Student 
 
Control Engineering Group 
Faculty of Electrical Engineering 
University of Twente 
The Netherlands 

[RTnet-developers] Re: [RTnet-users] about "context" in rtdm

[Jan K. <jan...@we...>]

Zhang Yuchen wrote:
> Hi,
> in last 2 weeks, I made the progress in understanding of rtnet
> internals. next week, I will switch back to firewire.
> 
> But currently, I still have some unclear points in rtnet, one of
> which is about the "context" in rtdm. To my current knowledge of
> rtnet, rtdm is a kind of demultiplexer for operations of the devices
> in its list. So when the standard API functions (BSD Socket) are
> invoked, the rtdm first will examine the protocol family and socket
> type to get the corresponding device, and then invoke the
> corresponding operation.(Please fix me if I am wrong.)
> 

Correct. BTW, the same applies to devices which are registered by a 
clear-text name (like the RTmac/TDMA discipline device "TDMAx").

> But why we need a "context" here? Since the "device" is fetched
> during creating the socket, the other operations, like read_rt and
> write_rt, can also be fetched via the prefetched device, right? Could
> you please give me more explanation of the "context"?
> 

The context stores information about the instance of the opened device 
like the caller's context (kernel/user), a usage counter, potentially 
overloaded device operations, and any device-specific data. In case the 
device allows only a single opener, these informations could also be 
stored together with the device structure. Actually, this is done for 
such devices by linking a single pre-allocated structure via 
exclusive_context.

But if the device allows multiple instances at the same time as the 
protocol devices of RTnet do, you have to provide independent context 
structure which are created upon open. This allows to have e.g. several 
UDP ports to be used by different applications without interfering each 
other - as one expects it.

Jan


PS: rtn...@li... :)

[RTnet-developers] Build dependencies on 2.6

[Jan K. <ki...@rt...>]

Hi all,

after we have RTnet now compiling and running on kernel 2.6, we noticed 
a major shortcoming of RTAI's (and now also RTnet's) current build 
concept for this version - at least from the developer point of view: 
The dependencies are not generated, and thus changes in headers do not 
trigger the required module recompilations.

Are there any efforts, plans, concepts to solve this issue in RTAI? I 
currently feel like we are back in RTnet's pre-autotools age - if in 
doubt, "make clean; make" (we even had this hardcoded in the Makefile).

If someone has a feasible idea, I guess, Marc would be quick to code it 
down... ;)

Jan

Re: [RTnet-developers] Re: [RTnet-users] Thoughts on new source layout

[Jan K. <ki...@rt...>]

Jan Kiszka wrote:
> Marc Kleine-Budde wrote:
> 
>> fixed in svn
>>
>>  
>>
> Good. And I'm currently testing a solution for that USE_COUNT issue. 
> rtnet_rtpc.c is already fixed and will be uploaded soon.
> 

Well, if I did not oversee something, we should have a cleanly compiling 
RTnet for kernel 2.6 now!

I did not tested anything yet, and there are a few drivers remaining to 
be fixed. However, I'm surprised that it was that simple to migrate the 
source code (not knowing how much work it took for you, Marc).

Jan

Re: [RTnet-developers] Re: [RTnet-users] Thoughts on new source layout

[Jan K. <ki...@rt...>]

Marc Kleine-Budde wrote:

>fixed in svn
>
>  
>
Good. And I'm currently testing a solution for that USE_COUNT issue. 
rtnet_rtpc.c is already fixed and will be uploaded soon.

Jan

Re: [RTnet-developers] Re: [RTnet-users] Thoughts on new source layout

[<kle...@gm...>]

On Thu, Oct 28, 2004 at 10:15:56PM +0200, Jan Kiszka wrote:
> >>I've just commited the latest changes to svn. This is the first
> >>linux-2.6 enabled version. Feel free to test and comment :)

> >I've forgotten to convert rtai_rtdm - I'll do this tomorrow.

fixed in svn

Marc

-- 
#!/bin/sh
set - `type $0` 'tr "[a-zA-Z]" "[n-za-mN-ZA-M]"';while [ "$2" != "" ];do \
shift;done; echo 'frq -a -rc '`echo "$0"| $1 `'>$UBZR/.`rpub signature|'`\
echo $1|$1`'`;rpub "Jr ner fvtangher bs obet. Erfvfgnapr vf shgvyr!"'|$1|sh

Re: [RTnet-developers] Re: [RTnet-users] Thoughts on new source layout

[Jan K. <jan...@we...>]

Marc Kleine-Budde wrote:
> On Thu, Oct 28, 2004 at 09:44:13PM +0200, Marc Kleine-Budde wrote:
> 
>>I've just commited the latest changes to svn. This is the first
>>linux-2.6 enabled version. Feel free to test and comment :)
> 

Great! I will check what the compiler doesn't like.

> 
> smc91111 is not working - any volunteers :)

Will have a look. Mmh, just wondering if we may once have 2.6 with RTnet 
on that SSV board with smc91111 we recently bought for a student's thesis...

> I've forgotten to convert rtai_rtdm - I'll do this tomorrow.
> 

Ok, I think there is already enough to fix for me :)

Jan

Re: [RTnet-developers] Re: [RTnet-users] Thoughts on new source layout

[<kle...@gm...>]

On Thu, Oct 28, 2004 at 09:44:13PM +0200, Marc Kleine-Budde wrote:
> I've just commited the latest changes to svn. This is the first
> linux-2.6 enabled version. Feel free to test and comment :)

smc91111 is not working - any volunteers :)
I've forgotten to convert rtai_rtdm - I'll do this tomorrow.

> NOTE: This warnings effect only RTnet with linux-2.6.x

Marc

-- 
#!/bin/sh
set - `type $0` 'tr "[a-zA-Z]" "[n-za-mN-ZA-M]"';while [ "$2" != "" ];do \
shift;done; echo 'frq -a -rc '`echo "$0"| $1 `'>$UBZR/.`rpub signature|'`\
echo $1|$1`'`;rpub "Jr ner fvtangher bs obet. Erfvfgnapr vf shgvyr!"'|$1|sh

Re: [RTnet-developers] Re: [RTnet-users] Thoughts on new source layout

[<kle...@gm...>]

Hi!

I've just commited the latest changes to svn. This is the first
linux-2.6 enabled version. Feel free to test and comment :)

Jan, please have a look at the deprecated MOD_INC/DEC_USE_COUNT
warnings. There is also undefined __MOD_INC_USE_COUNT.

NOTE: This warnings effect only RTnet with linux-2.6.x

Marc

-- 
#!/bin/sh
set - `type $0` 'tr "[a-zA-Z]" "[n-za-mN-ZA-M]"';while [ "$2" != "" ];do \
shift;done; echo 'frq -a -rc '`echo "$0"| $1 `'>$UBZR/.`rpub signature|'`\
echo $1|$1`'`;rpub "Jr ner fvtangher bs obet. Erfvfgnapr vf shgvyr!"'|$1|sh

[RTnet-developers] Re: [RTnet-users] Thoughts on new source layout

[Jan K. <ki...@rt...>]

Marc Kleine-Budde wrote:
> 
> I've renamed core to stack, and commited to svn
> 

Looks and compiles very nice!

Jan

[RTnet-developers] Re: [RTnet-users] Thoughts on new source layout

[<kle...@gm...>]

On Wed, Oct 27, 2004 at 01:11:07PM +0200, Jan Kiszka wrote:
> >>>'core' may be a disadvantageous name....perhaps configure tries to
> >>>delete 'core'-files from segfauled processes etc...

> >>Yes, there are some code about this in configure. What to do? Do you 
> >>have a better name at hand?
> >rtnet-core
> Mmh, then we end up with the RTAI 3.0 way: rtnet-xxx or rtnet_xxx. What 
> about "stack"? I think this also hits the mark.

I've renamed core to stack, and commited to svn

Marc

P.S.: still 2.4 only :)

-- 
#!/bin/sh
set - `type $0` 'tr "[a-zA-Z]" "[n-za-mN-ZA-M]"';while [ "$2" != "" ];do \
shift;done; echo 'frq -a -rc '`echo "$0"| $1 `'>$UBZR/.`rpub signature|'`\
echo $1|$1`'`;rpub "Jr ner fvtangher bs obet. Erfvfgnapr vf shgvyr!"'|$1|sh

[RTnet-developers] init mail

[<kle...@gm...>]

erster

Marc
-- 
#!/bin/sh
set - `type $0` 'tr "[a-zA-Z]" "[n-za-mN-ZA-M]"';while [ "$2" != "" ];do \
shift;done; echo 'frq -a -rc '`echo "$0"| $1 `'>$UBZR/.`rpub signature|'`\
echo $1|$1`'`;rpub "Jr ner fvtangher bs obet. Erfvfgnapr vf shgvyr!"'|$1|sh