taskTransport Sample Protocol - Tasks: task #8391, Allow user's space writing in a...

 
 

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

task #8391: Allow user's space writing in a Kernel Blackboard.

Submitted by:  Jerome Arbez-Gindre <jaggy>
Submitted on:  Wed 09 Jul 2008 03:41:53 PM UTC  
 
Category:  Blackboard 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:  In Progress Privacy:  Public
Percent Complete:  0% Assigned to:  Jerome Arbez-Gindre <jaggy>
Open/Closed:  Open Effort:  0.00

Wed 23 Jul 2008 03:23:11 PM UTC, comment #4:

For now, I propose to allow a userspace writable kernel BB by a CMAKE option.
By this way, I can add a comment to say that it's dangerous and can produce kernel crashes !!

Jerome Arbez-Gindre <jaggy>
Project MemberIn charge of this item.
Thu 10 Jul 2008 11:55:59 AM UTC, comment #3:

I'm OK with the

let the application to handle race condition problems... to avoid the complexity of a generic and systematic solution.

Concerning the "kind of user/kernel" RPC I'll comment
on the other task.

Eric NOULARD <erk>
Project Administrator
Thu 10 Jul 2008 11:39:01 AM UTC, comment #2:

For my point of view (And our actual needs),
I would prefer to let the application to handle race condition problems... to avoid the complexity of a generic and systematic solution.

(Note that the task "#8392: Implement message passing in kernel Blackboard" is linked to this one)
My aim is to implement a sort of RPC user space/kernel space.

Jerome Arbez-Gindre <jaggy>
Project MemberIn charge of this item.
Wed 09 Jul 2008 04:56:14 PM UTC, comment #1:

Multiple write access to the same Blackboard in different
context (user/kernel) or different thread like
two [concurrent] threads accessing the same BB
may be dangerous.

If your blackboard is designed such that each "context"
only write on some part and the other is only "reading"
another part it may work besides the fact that the reader
should be prepared to read JAM sometime.

If you really need "coherent" protected access you
should (may be) implement bb_lock/bb_unlock or
may be use 2 (or more) blackboard in order to gives
write access only on one side (kernel or user) on each
blackboard.

The lock solution is used by the Blackboard provider.
In fact it uses a "shadow blackboard" in order
to minimize locking time.
A shadow blackboard is a copy of a "master" Blackboard
which meant to be used only in a readonly fashion.
You do
bb_shadow_get once
then you do
bb_shadow_update_data each time you want

You may imagine a kind of
bb_shadow_sync operation which may synchronize
the shadow and the master in a safe way.

Eric NOULARD <erk>
Project Administrator
Wed 09 Jul 2008 03:41:53 PM UTC, original submission:

The aim of this task is just allowing the user's space to write in shared memory.. not allowing user's space to publish data.

Short term solution:

Just remove the 2 lines avoiding a write mmap in "bb_map" and perform a mmap call with PROT_WRITE in k_bb_shmem_attach.
This solution is not perfect because a user space bug could generate troubles in kernel.

Long term solution:

Allocating 2 memory buffers (aligned on page size), one for BB data, one for published data themselves. The BB data would be protected... and published data would not.

Jerome Arbez-Gindre <jaggy>
Project MemberIn charge of this item.

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    No changes have been made to this item

    Back to the top


    Powered by Savane 3.4