Hi, > all elements that have the same hash key end up in the same list
Ok, I missed that and the rest of the patch is wrong b/c of this. I did what you said and created a second hash table indexed by device + offset, leaving all code for dev_pager_hashtable untouched. I tried to insert the same dev_pager_entry in both lists to avoid duplication, but the links field can't be shared between two lists, so I created a new struct dev_device_entry for the devices hash. I also created the equivalent to dev_device_hash[init,insert,delete,lookup] functions for the devices hash, so I don't have to make changes in any of the pagers hash functions, but I could merge these functions for both hashes to avoid the duplication if you think it's better. Finally I renamed the hash macros since now they are not exclusive for the pagers hash. There's another thing I don't understand: One task can call device_map on a device and offset for the first time, then dev_pager setup will allocate the pager and insert it on the hash. Later, another task can call device_map on the same device and offset, then dev_pager_setup will find it in the hash and return a name for the same pager, so two tasks are sharing the pager, is not that a security problem? > adding to gnu mach a function that returns a memory proxy for a given range > of memory, that would also make a lot of sense If you think it's safe to return a pager belonging to the same task who requested it, then I'll do it.
