tsp-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tsp-devel] Utilisation du BB sous Rtems


From: Eric Noulard
Subject: Re: [Tsp-devel] Utilisation du BB sous Rtems
Date: Mon, 5 Nov 2007 15:17:16 +0100

Le 05/11/07, Frederik Deweerdt<address@hidden> a écrit :
 > Peux-tu nous donner le/s lien/s (url) d'où tu as tiré la phrase
> > "malloc'ed memory is shareable across all threads." ?
> Il s'agit de http://www.rtems.com/ml/rtems-users/2007/november/msg00003.html

Ok vu.

> effectivement, même sur la doc de la version de dev de rtems, la fontion
> est documentée comment n'étant pas implémentée.
> http://www.rtems.com/onlinedocs/releases/rtemsdocs-4.7.99.2/share/rtems/html/posix1003_1/posix1003_100229.html

Exact j'avais lu ça mais ce n'était pas clair (en tout cas dans mon esprit)
que la non implémentation venait du fait qu'il n'y pas de protection
mémoire inter-process.

> Ca ferait donc
> bb_create == malloc (la clé serait l'adresse allouée, le seul ennui à
> mon avis c'est qu'il ne sera pas possible de décider si il faut faire un
> bb_attach ou un bb_create)
> bb_lock == sem_open()
> bb_msg_snd == mq_send() (lui est implémenté dans la dernière version en
> tout cas)

je suis d'accord.

>
> L'idéal, ça serait peut-être d'implémenter un shm_open() autour de malloc,
> de manière à ce qu'on puisse réutiliser le code msg et sem pour faire
> du BB POSIX sous les autres systèmes.

Oui très bonne idée d'autant que ça permettrait de résoudre
le pb de faire la différence entre create et attach,
cette imlémentation de
shm_open pourrait "bêtement"  conserver dans une zone statique
la liste des shm_open déjà effectué.

Ce pourrait même être une contribution pour RTEMS
qui permettrait d'utiliser les API shm_open et shm_unlink
pour d'autres applis tout en sachant que leur
sémantique est proche de malloc/free sous RTEMS.

<parenthèse type="regrets">
Ce qui est idiot c'est une version primitive du BB
(qui n'a jamais atteind le CVS)
le code pour utiliser les API POSIX (shm_xxx, sem_xxx, mq_xxx)
était présent encadré par des #ifdef POSIX_IPC  ...

Comme à l'époque les messages queues POSIX n'étaient
pas dispo (sans patche) sous Linux, ben j'avais 'nettoyé' le code
avant le premier commit :-(

Je vais voir si je retrouve ça dans le coin d'un disque mais
il y a peu de chance...
</parenthèse>

-- 
Erk




reply via email to

[Prev in Thread] Current Thread [Next in Thread]