[Kos-dev] Re: Meditations de la journee

[Thomas Petazzoni]

David Decotigny <David.Decotigny@irisa.fr> writes:

>    + Je suis tjs embete par ces 2 poids/2 mesures pour les 2 types de
>      methodes pour les shadow_resource : methodes vmm et babel
>      (methodes de translator->interface). On se demande pourquoi
>      toutes les methodes ne sont pas rassemblees dans translator par
>      exemple. Or je pense que mettre les vmm_drv dans translator amene
>      a tout melanger, donc que c'est pas une bonne idee. Malgre tout,
>      on a l'impression que la on a un truc bancal alors que c'est
>      faux. Peut-etre qu'avoir un nommage coherent dans la def des
>      membres de struct shadow_resource suffirait, du genre
>      "babel_drv"/"vmm_drv". Ou
>      "babel_translator"/"vmm_translator". Bref, qqch d'un peu plus
>      symetrique.

Je ne suis pas pour une generalisation des vmm_drv, car ils ne
concernent qu'un seul type de shadow resource : les shadow resource
mappables en memoire. Certaines shadow resource en effet ne seront pas
mappables en memoire (ex : /dev/fs/fat0, /dev/team/team0, etc...). Le
vmm_drv est un ajout de la partie VMM a un objet du systeme pour
pouvoir le gerer comme il le faut.

Ceci dit, je suis pret a etudier toute proposition visant a modifier
l'existant. Je ne vois pas exactement comment tu veux faire d2,
pourrais-tu expliciter un peu plus ?

>  - sr->name : parce que les sr peuvent etre recopies par le noyau, le
>    sr->name doit etre alloue dynamiquement partout (sinon ca foire au
>    cleanup : kfree(sr->name)). J'ai vu des cas ou on avait des trucs
>    du style sr->name = "/"; La ou j'ai vu ca, j'ai rectifie par un
>    strdup("/"); Je suis pas sur de n'avoir rien oublie (en
>    particulier, il reste surement des memcpy(new_sr, old_sr, size)
>    sans le new_sr->name = strdup(old_sr->name) qui va bien).

Oui effectivement, nous n'etions pas tres prudents vis a vis des noms,
et j'ai dit plusieurs fois a Julien pendant la semaine "ca serait
quand meme bien un petit strdup".

Et sinon d2, le probleme des locks au niveau de bbl_open_sr, tu en
penses quoi ? Et dans l'ensemble mis a part les quelques remarques,
que penses-tu du travail ? Cela va-t-il dans le sens ou tu pensais que
les choses iraient ?

D'autre part, j'avais enleve le module ipc du CVS il me semble,
quelqu'un l'a remis ? (je l'avais peut etre mal supprime, c'est
possible).

Bonne journee,

Thomas
-- 
PETAZZONI Thomas - thomas.petazzoni@enix.org - UIN : 34937744
(Perso)      http://www.enix.org/~thomas/
(KOS)        http://kos.enix.org/ 
(Club LinUT) http://club-linut.enix.org