[SOS] Problème de compréhension

[Thomas Petazzoni]

Bonjour,

Cyril Dupuit wrote:

> Je n'arrive pas à comprendre le schéma globale des objets (range, slab, 
> cache) mis en oeuvre. Pourriez-vous m'aider à comprendre cette 
> initialisation.

Il y a deux parties distinctes dans l'allocateur :

  - Un allocateur de "ranges" dans l'espace noyau. Cet allocateur permet 
d'allouer des espaces de mémoire dont la taille est un multiple de la 
taille d'une page. Cet allocateur par "ranges" repose sur le second 
allocateur pour allouer les "struct range" (c'est là la subtilité)

  - Un allocateur ala "malloc()", c'est à dire un allocateur qui permet 
d'allouer des objets de petite taille (< taille d'une page). Différents 
types d'allocateurs existent pour faire cela, mais pour SOS, nous avons 
choisi un allocateur par "slab". Dans un allocateur par "slab", on créé 
un cache pour chaque type ou taille d'objet que l'on souhaite allouer. 
Ainsi, dans un OS, on crééera certainement un cache pour les objets 
"semaphore", un cache pour les objets "thread", un cache pour les objets 
"fichier", un cache pour les objets divers de 16 octets, un cache pour 
les objets divers de 32 octets, un cache pour les objets divers de 64 
octets, etc... Et ensuite, on va puiser dans ces caches en fonction de 
l'objet que l'on souhaite allouer. Chaque cache est un ensemble de 
"slab". Un "slab" est lui même un ensemble de pages virtuelles contigues 
découpées de manière arbitraire pour former des zones de la taille 
unitaire d'un objet du cache considéré. Et là, de nouveau la subtilité : 
cet allocateur repose sur le premier allocateur. En effet, un slab 
n'étant qu'un ensemble de pages virtuelles contigues, on utilise le 
premier allocateur pour allouer un "range" !

Voilà, je ne sais pas si c'est plus clair, n'hésite pas à poser d'autres 
questions si besoin est.

> - Dans les fonctions create_cache_of_caches et create_cache_of_ranges, 
> vous faites appel à la fonction : cache_initialize. Cette fonction, 
> comme son nom l'indique, sert à initialiser un cache.
> Pourtant, je ne comprend pas pourquoi the_cache est initialisé à 0 pour 
> une taille de sizeof(struct sos_kslab_cache) lorsque d'autres fonctions 
> de ce module (sos_kmem_cache_create, create_cache_of_caches, 
> create_cache_of_ranges) utilisent cette fonction avec un paramètre de 
> taille de sizeof_struct_range ou obj_size. Si obj_size > sizeof(struct 
> sos_kslab_cache), c'est bon. Par contre, sizeof_struct_range est 
> inférieur à sizeof(struct sos_kslab_cache) d'où un bogue latent.

Dans cache_initialize(), je vois :

   memset(the_cache, 0x0, sizeof(struct sos_kslab_cache));

the_cache est donc invariablement initialisé à 0 pour une taille de 
sos_kslab_cache.

Le paramètre obj_size de cache_initialize() est effectivement pour 
chaque appel de cache_initialize(). Mais obj_size désigne la taille des 
objets contenus dans ce cache. Dans le cas du cache des caches, obj_size 
vaut sizeof(struct sos_kslab_cache), dans le cas du cache des ranges 
obj_size vaut sizeof(struct range), etc...

Je ne vois pas où est le problème que tu soulèves.

> - Autre problème dans la fonction sos_kmem_vmm_free. Le type retourné 
> est : sos_vaddr_t qui cache un type unsigned long. En cas d'erreur, 
> cette fonction retourne -SOS_EINVAL ou -SOS_EBUSY.

Oui, la bonne pratique mise en place par d2 aurait je pense voulu que la 
fonction sos_kmem_vmm_free() retourne un sos_ret_t, et que la véritable 
sos_vaddr_t soit retournée via un pointeur.

Bonne journée,

Thomas
-- 
PETAZZONI Thomas - thomas.petazzoni at enix.org
http://thomas.enix.org - Jabber: thomas.petazzoni at jabber.dk
KOS: http://kos.enix.org/ - Lolut: http://lolut.utbm.info
Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E  1624 F653 CB30 98D3 F7A7
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://the-doors.enix.org/pipermail/sos/attachments/20041115/f3c21412/signature.pgp