taskTransport Sample Protocol - Tasks: task #8392, Implement message passing in...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

task #8392: Implement message passing in kernel Blackboard

Submitter:  Jerome Arbez-Gindre <jaggy>
Submitted:  Wed 09 Jul 2008 03:50:18 PM UTC
   
 
Category:  None Should Start On:  Wed 09 Jul 2008 12:00:00 AM UTC
Should be Finished on:  Wed 09 Jul 2008 12:00:00 AM UTC Priority:  5 - Normal
Status:  Done Privacy:  Public
Assigned to:  jaggy Percent Complete:  100%
Open/Closed:  Open Effort:  0.00

Jump to the original submission

Fri 11 Jul 2008 06:33:03 PM UTC, comment #14: 

I'm OK with this too.

B_BLACKBOARD_SEPARATE_SHARED for "apparently more" intrusive implementation

LOCAL_DATA concept in main.

GO ahead.

Eric NOULARD <erk>
Group administrator
Fri 11 Jul 2008 04:28:47 PM UTC, comment #13: 


> - Implement in main branch the LOCAL_DATA concept explained in comment #11 with callback mechanism.


I second that, the rationale being that we want this feature in the upcoming TSP release. So lets introduce the feature in a non intrusive way for now, and make the more intrusive changes once we've got solid non-regression tests.

Frederik Deweerdt <deweerdt>
Group administrator
Fri 11 Jul 2008 04:26:30 PM UTC, comment #12: 

the file

https://savannah.nongnu.org/task/download.php?file_id=16104

is a patch which implement what is explained in the Comment #10.

To go further, I propose this:
- Put this patch in a Branch (called for example B_BLACKBOARD_SEPARATE_SHARED) and continue some dev on it.
- Implement in main branch the LOCAL_DATA concept explained in comment #11 with callback mechanism.

- Eventually Merge later the B_BLACKBOARD_SEPARATE_SHARED in main.

Jerome Arbez-Gindre <jaggy>
Group Member
Fri 11 Jul 2008 09:51:12 AM UTC, comment #11: 

I think we should discuss this face-to-face
but some information regarding BB evolution:

0) If you want to modify S_BB_T
   think twice: is it really necessary.
   Normally new extension should use
   S_BB_PRIV_T.

1) if S_BB_T needs evolution then
   bb_core.h::BB_VERSION_ID should be changed
   and compatibility mode should be setup
   in bb_core.c::bb_check_version

Now I think you may look at the zipped name
var extension and its S_BB_PRIV structure usage
(browse bb_core.[hc] and bb_varname_*[hc])

The idea of S_BB_PRIV is to put extension data
"at the end" of the BB such that older version
of BB enabled application would not be disturb by
the new extensions.

In you case I don't think you need that because
you only want "private+local" data so you "only" need
a map for getting private+local data out of a
S_BB_T pointer.

You may have S_BB_LOCAL_DATA_T structure and
a "library wide" static which maps
S_BB_T* to a S_BB_LOCAL_DATA_T* pointer.


Eric NOULARD <erk>
Group administrator
Fri 11 Jul 2008 09:28:52 AM UTC, comment #10: 

To implement the callback mechanism, I need to add data in the S_BB structure.

The actual design is problematic in this context because the data I have to add is specific to a particular BB client and should not be shared with other client.
In fact, I would need to store (for example) callback pointer which will have sense only in the client context (and memory mapping !).

Actually, clients are handling pointers on a shared S_BB structure.
I propose to change that by:

- renaming S_BB_T in S_BB_MAPPED_T
- create a struct
typedef struct S_BB {
    struct S_BB_MAPPED_T * mapped_bb;
    /* everything specific for each client */
} S_BB_T;

This way of doing have key advantages:
- Do not break the API.
- Do not break the Binary compatibility (an "old" bb_lib should be able to attach on a "new" bb);
- Actually, their is pointer stored in the S_BB_T. These pointers have only sense in a particular context/adress space... They probably could be moved in the new struct S_BB.

Jerome Arbez-Gindre <jaggy>
Group Member
Fri 11 Jul 2008 08:49:42 AM UTC, comment #9: 

Yep, it is basically the same thing, its just more convenient to have the message recieve as a callback on the kernel side.

Frederik Deweerdt <deweerdt>
Group administrator
Fri 11 Jul 2008 08:45:55 AM UTC, comment #8: 

OK I think I understand the need.

This is the same scheme as the one implemented
between bb_tsp_provider and bb-enabled application
have a look at

tsp/src/util/libbb/bb_simple.c:
bb_simple_synchro_go
bb_simple_synchro_wait

and is usage in:
tsp/src/util/libbb/bbtools/bb_simu.c (the fake application)
tsp/src/providers/bb_provider/bb_tsp_provider.c (BB tsp provider)

The only difference is that currently we use
bb_lock+bb_unlock+bb shadow.

Eric NOULARD <erk>
Group administrator
Thu 10 Jul 2008 12:34:15 PM UTC, comment #7: 

comment #5 response:

            OK for me with all of this.

comment #6 response:

     In fact, we only need user->kernel synchronous calls (mainly set/get functions)

     I have thought building such a mechanism on top of BB shared memory for the parameter passing (can be HUGE !) and BB msgs for the synchronous aspect.
    
     For example:

          Set a set of configuration params:

           1- write the all config prameters in BB memory
           2- send a SET msg
           3- wait the ACK msg

          Get a set of counter:

           1- send a GET msg
           2- wait the ACK msg
           3- Read the counters from BB memory

In fact, I just want to improve Kernel BB implementation to allow us to use BB messaging ability.

Jerome Arbez-Gindre <jaggy>
Group Member
Thu 10 Jul 2008 12:07:40 PM UTC, comment #6: 

If your need is a kind of user/kernel RPC then
you may have to enrich the current message queue usage
in order to be able to pass function and argument value.

Usually RPC need is to call a function
(which could be a message 'mtype') and it's argument
(which could be in the message 'mtext').

However if you are about to implement a kind of
user to kernel RPC
won't it be the same feature as a syscall or ioctl?
May be ioctl on /dev/bb would be the way to go?

Do you need this same RPC feature for user-to-user
BB application?



Eric NOULARD <erk>
Group administrator
Thu 10 Jul 2008 11:54:18 AM UTC, comment #5: 


> I propose to add two function in
> bb_core.h


bb_core should be minimal and contains
"core" functionnality which cannot be implemented
already-there API.
(that's why there is a bb_simple.[hc]
 and even a bb_alias.[ch])
Moreover I do not like the idea of "core"
functionnality which starts and stops threads.
BB was designed to be an easy, efficient
and low-overhead mean for inter-applications/processes communications.
Starting and stopping thread costs you time and space.

Thus I would rather define this new API separately
(which is nevertheless useful):
bb_callback.[hc] or bb_messaging.[hc] for example:

since

> int32_t bb_subscribe_to_msg(S_BB_T bb, S_BB_MSG_T msg, void (callback)(S_BB_T bb, S_BB_MSG_T* msg);
> which would launch a thread waiting on a bb_rcv_msg call an then call the "callback".


Then user must be careful on how it implements the callback
since it will be concurrently running with the thread who
has "bb_subscribe_to_msg".

>int32_t bb_unsubscribe_to_msg(S_BB_T bb, S_BB_MSG_T msg);
>which would stop the thread.


APIs seems pretty simple to implement (in userland) on top of current bb_core API.

I may suggest another name for the API

bb_msg_subscribe
bb_msg_unsubscribe




Eric NOULARD <erk>
Group administrator
Thu 10 Jul 2008 08:08:43 AM UTC, comment #4: 


> What do you mean by "message passing"?
>
> Is it
> bb_msgq_XXXX?


Yes...

For the new API discussion, I propose to add two function in

bb_core.h

int32_t bb_subscribe_to_msg(
            S_BB_T bb, S_BB_MSG_T msg,
            void (callback)(S_BB_T *bb, S_BB_MSG_T msg);

which would launch a thread waiting on a bb_rcv_msg call an then call the "callback".

int32_t bb_unsubscribe_to_msg(
            S_BB_T bb, S_BB_MSG_T msg);

which would stop the thread.



Jerome Arbez-Gindre <jaggy>
Group Member
Wed 09 Jul 2008 05:02:02 PM UTC, comment #3: 


> I would like too discuss a way to improve msg passing API:
> I would need to implement a mechanism of callback when a message
> is received.


Go ahead make a proposal.
You would like a callback instead of polling?

Currently the idea of the message passing API is
to be polled regularly in a blocking because it
was done on purpose for synchronization.

How do you plan to implement synchronous callbacks
which works for multiple processes?

Do you want to interrupt the task using the BB
instead of making it handle a thread waiting for a message?

A kind a software interrupt or signal?
Could you tell us more about the need and your current
implementation ideas?


Eric NOULARD <erk>
Group administrator
Wed 09 Jul 2008 04:28:45 PM UTC, comment #2: 

What do you mean by "message passing"?

Is it
bb_msgq_XXXX?

I didn't know connector before reading
/Documentation/connector/connector.txt
but it looks nice.

Eric NOULARD <erk>
Group administrator
Wed 09 Jul 2008 04:26:13 PM UTC, comment #1: 

I would like too discuss a way to improve msg passing API:

I would need to implement a mechanism of callback when a message is received.

This allow users to not block a thread on a waiting call and to implement synchrone mechanisms.

Jerome Arbez-Gindre <jaggy>
Group Member
Wed 09 Jul 2008 03:50:18 PM UTC, original submission:  

At this time no message passing is implemented in the kernel BB.
One way to implement it would be to use kernel connectors.
(kernel sources /Documentation/connector/connector.txt)

Jerome Arbez-Gindre <jaggy>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #16104:  BB_shared.patch added by jaggy (43KiB - text/x-diff - Patch which implements the concept explained in the comment #10.)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by deweerdt (Posted a comment)
  • -email is unavailable- added by erk (Posted a comment)
  • -email is unavailable- added by jaggy (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-07-23 jaggy StatusIn Progress Done
        Percent Complete0% 100%
    2008-07-11 jaggy Attached File- Added BB_shared.patch, #16104

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code