I forgot to answer this:
Sergey Bugaev, le sam. 30 oct. 2021 15:06:30 +0300, a ecrit:
> > > Should the implementation cap the length to that of the entry
> > > silently, or should it return an error if called with an overly long
> > > len argument?
> > >
> >
> > I don't know, Samuel, what do you
Hello,
Andrea Monaco, le mar. 26 oct. 2021 23:09:56 +0200, a ecrit:
> this is trivial maybe, but the comment above netfs_startup doesn't
> document the return value. If I got it right, we can add it.
Applied, thanks!
Samuel
On Sat, Oct 30, 2021 at 3:06 PM Sergey Bugaev wrote:
> But
> memory_object_create_proxy () does add a reference to the memory
> object by doing ipc_port_copy_send (object[0]). It would seem that it
> should not do that; but then I'm not sure why this doesn't cause a
> leak — I know Samuel has
Joan Lledó, le sam. 30 oct. 2021 08:38:23 +0200, a ecrit:
> > I don't think you can access the entry once you've unlocked the map.
> >
>
> You're probably right b/c it doesn't seem the entry is being accessed after
> the lock release in any other place of the code.
You have to, yes. The problem
On Sat, Oct 30, 2021 at 9:38 AM Joan Lledó wrote:
> El 24/10/21 a les 19:50, Sergey Bugaev ha escrit:
> > I would expect the request port argument to be a vm_task_t (i.e. a
> > vm_map), not a full task. But I see that you need to pass
> > task->itk_space to memory_object_create_proxy (). But
> >
Hi,
El 24/10/21 a les 19:50, Sergey Bugaev ha escrit:
Naming: perhaps memory_object_create_vm_proxy ()? or even
memory_object_create_task_vm_proxy ()?
I don't care about the name, you guys decide.
I would expect the request port argument to be a vm_task_t (i.e. a
vm_map), not a full task.
