[Kos-dev] Suppression du gpfme->lock

d2 kos-dev@enix.org
24 Mar 2002 16:40:24 +0100


Hello,

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@enix.org> writes:
    Thomas> => Cf mon log de commit, j'ai change tout ca. Les pages
    Thomas> que tu savais d'ou elles venaient moi je sais, et je te
    Thomas> dirais pas ;)) Nan je rigole. C'est tout simplement les

Ok. Bien.

    Thomas> Effectivement, je vois le merdier. En fait l'objet gpfme
    Thomas> est protege par deux locks distincts, et c'est ca qui va
    Thomas> pas.

Oui. Il y a bien la solution : tous locks sur les gpfme. En principe,
ca suffit (pas besoin de lock sur les listes), a condition de posseder
les locks sur les prev/next des sources src/dest qd on bouge un gpfme
d'une liste a l'autre. Et l'ordre d'acquisition peut etre arbitraire
(p.ex : dependant de gpfme->address).

    Thomas> J'ai pas fait exactement comme tu as dis, mais ma
    Thomas> solution, est AMHA beaucoup plus simple, cf log de commit.

Oui, j'ai vu. Mais ce qui me gene, c'est que ca reste du parcours de
PD/PT. Meme si c'est vrai que tu le fais sur un espace bcp bcp bcp bcp
moins large. Pour la petite histoire, j'avais cherche un truc comme
ton parcours des ranges, mais je me souvenais plus qu'en dessous de VR
y'avait des ranges. Or en voyant la VR noyau sur 2G, je me suis dit
qu'il valait mieux eviter de la parcourir, et qu'on avait interet a
faire plus """fin""" (ie 128M, c'est vachement plus fin que 2G
non...:). Et pourtant il me semblait bien que qqpart on se retapait
une sorte de quadrillage de la VM, mais j'me suis dit "j'ai du rever,
ca devait etre pmm et la mem physique plutot que virtuelle". D'ou le
truc bourrin de chez bourrin... et encore, j'aurais pu parcourir les
2G, j'en aurais ete capable, si si ;).

Ceci dit, je suis chieur et je continue de penser que ca serait plus
elegant d'initialiser proprement tout au plus tot, et d'eviter de
parcourir les PD/PT pour plus de 4 pages. Donc si tu sais pas quoi
faire...

    Thomas> Derniere question : un fichier est vu comme un
    Thomas> peripherique caractere au niveau de l'API Unix. Qui
    Thomas> realise cette abstraction ? La libc ou le noyau ? (sur
    Thomas> disque, un fichier est plutot un peripherique en mode
    Thomas> bloc).

Pourquoi comme un periph caractere ? A partir du moment ou tu peux
faire seek dessus, c'est du bloc. Enfin j'ai du comprendre la question
de travers.

Bonne journee,

-- 
d2