Sergey Bugaev, le lun. 16 août 2021 21:59:47 +0300, a ecrit: > On Mon, Aug 16, 2021 at 9:17 PM Samuel Thibault <samuel.thiba...@gnu.org> > wrote: > > > > I'd rather see a > > > > hurd-specific libpciaccess function to get the pager. > > > > > > That's better, but we'd have to add that function in both hurd_pci.c and > > > x86_pci.c. I don't like the idea of adding Hurd specific code to > > > x86_module > > > but there's already a lot of it and we could avoid the existence of struct > > > pci_user_data, which I like even less. > > > > Actually I'm thinking that this is just another case of mremap(). The > > underlying question is getting the memory object of a given memory > > range, like vm_region does. We need to be careful since we don't want > > any process to be able to get the memory object of any other process, > > but it does make sense, and would be useful for mremap. > > IMO the proper way to get mremap () is vm_remap ()
But that doesn't answer Joan's need for getting a memory object, to be able to put a proxy memory object on top of it to make it read-only. > This makes me think of something cooler though: what if there was an > API to create a proxy memory object from a (task, address, size) > triple? That wouldn't answer his need either: we don't want to access the task content, we want to access the underlying (PCI-mmapped) memory object. > routine vm_create_proxy ( > target_task : vm_task_t; > address : vm_address_t; > size : vm_size_t; > out proxy : memory_object_t); > > Then mremap () could be implemented like this: > > vm_create_proxy (mach_task_self (), old_address, old_size, &proxy); > vm_deallocate (mach_task_self (), old_address, old_size); > vm_map (mach_task_self (), new_address, new_size, ..., proxy, ...); > mach_port_deallocate (mach_task_self (), proxy); But then it'll create a pile of proxies if the application calls mremap several times, which I guess some applications will happily try to do. Samuel
