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.

Submitter:  Jerome Arbez-Gindre <jaggy>
Submitted:  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
Assigned to:  jaggy Percent Complete:  0%
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>
Group Member
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>
Group 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>
Group Member
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>
Group 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>
Group Member

 

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

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)
  •  

    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.

     

    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code