[Kos-dev] Suppression du gpfme->lock

[Thomas Petazzoni]

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

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

Ouais, ca pourrait se faire comme ca, mais c'est vrai que c'est quand
meme tres tres tres chiant !

> 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...

Euh, AMHA on peut pas le mettre plus tot ce truc la. Vraiment pas du
tout. Parce que on a besoin de rmap+kslab+pmm pour faire fonctionner
le tout, donc on peut pas le faire plus tot. Je vois pas du tout
comment tu veux faire autrement. La on parcourt les PT SEULEMENT sur
les pages allouees, y'en a AUCUNE qu'on scanne et qui n'est pas
mappee. Je vois pas comment tu peux faire plus optimal !

>     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.

fgetc retourne un caractere non ?

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