Synchronous Message Passing

Shravan Rayanchu rshravankumar at yahoo.com
Fri Oct 8 17:58:30 CEST 2004


Actually the problem is something like this:

we are actually developing a MAC layer. So the
constraint is that user will use Kernel space (via sys
calls) and call functions like "connect". Sys call
then, forms the CONNECT-REQUEST and has to give it to
an RT Task.(In local m/c). 

// I need to have some mechanism of passing this
request (basically few bytes of data.)

RT Task will handle the request. The Syscall then HAS
to wait till it gets a CONNECT-CONFIRM from the RT
Task (REQUEST and CONFIRM are both structures) and
then do some processing and the return to the user
(the outcome of connect request.)

CONSTRAINT : 
In my case, the RT Task, typically will have other
tasks to do, it wont call a rt_receive function and
wait!. That is, 'connect' is an ASYNCHRONOUS request
(the request can come at anytime) & RT Task wont be
waiting for it (RT Task wont block). 

// Any how rt_receive expects a RT Task to wait for,
while we are in a sys call (kernel space) - not an RT
Task.

RT Task will poll the FIFO or something occasionally
to check if there is a data and do some processing &
then returns CONFIRM structure. I called it
Synchronous message passing, cuz the sys call has to
WAIT till it gets a CONFIRM.

Please do help!

Thanks & regards,

Shravan


> 
> I do not understand the problem if you are writing a
> system call it 
> means that it has to be used by tasks anyhow.
> Moreove you have an RTAI 
> task in kernel space also. So whay not use RTAI rpc
> as it is, with the 
> adavantage of having it in distributed mode also
> (NETRPC).
> 
> It is not needed to be in real time to use RTAI in
> user space.
> 
> Once more your solution has the name: LXRT (IMHO).
> 
> Paolo.
> 
> 
> 


=====



		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com




More information about the Rtai mailing list