Hi,
El 1/11/21 a les 17:47, Sergey Bugaev ha escrit:
With this diff (on top of your patch), it finally works sanely for me:
Cool, great work. I'd like to try it myself but I won't have the time
until next weekend. I'll merge your changes with mine and make my tests.
Sergey Bugaev, le lun. 01 nov. 2021 19:47:06 +0300, a ecrit:
> That, and also proxies actually don't support non-zero offset, but
> they do support non-zero 'start' (I don't know what the difference was
> supposed to be between the two).
offset is inside the original object, and start is in the pr
Sergey Bugaev, le lun. 01 nov. 2021 22:59:59 +0300, a ecrit:
> On Mon, Nov 1, 2021 at 10:36 PM Samuel Thibault
> wrote:
> > offset is inside the original object, and start is in the proxy object.
> > Think for instance of /dev/mem, within which you could want to map some
> > VGA-compatible range
On Mon, Nov 1, 2021 at 10:36 PM Samuel Thibault wrote:
> offset is inside the original object, and start is in the proxy object.
> Think for instance of /dev/mem, within which you could want to map some
> VGA-compatible range at 0xA (that's the start), but the mapping
> range is a subpart of t
On Mon, Nov 1, 2021 at 7:13 PM Sergey Bugaev wrote:
> But again, let's try to get the simple version working first. As I've
> said, with vm_object_pager_create () it kind of works, except it
> doesn't give me the actual data for whatever reason.
Phew, I figured out why that was!
We were not calc
On Mon, Nov 1, 2021 at 6:44 PM Joan Lledó wrote:
> > * "Anonymous" mappings (created with a null memory object)
>
> If they provide no object when calling vm_map, then the kernel uses the
> default pager, isn't it?
Conceptually, yes. But the way it's implemented, the object->pager
port stays null
Hi,
El 1/11/21 a les 14:36, Sergey Bugaev ha escrit:
* "Anonymous" mappings (created with a null memory object)
If they provide no object when calling vm_map, then the kernel uses the
default pager, isn't it? Can't you send a reference to the default pager
to memory_object_create_proxy()?
So I've applied the patch and have tried to actually exercise the new
functionality.
And unfortunately, I'm reminded (by a kernel panic and a corrupted
filesystem) of the two important cases that we have forgot:
* Submaps
* "Anonymous" mappings (created with a null memory object)
Submaps could b
On Sun, Oct 31, 2021 at 8:44 PM Svante Signell wrote:
> One alternative to the path_max.diff patch is to simply do:
> #ifndef PATH_MAX
> #define PATH_MAX 4096
> #endif
> in xf86drm.c. This is a patch that upstream would accept more easily than the
> proposed one, but is not very Hurdish.
>
> WDYT?
From: Joan Lledó
To get a proxy to the region a given address belongs to,
with protection and range limited to the region ones.
* include/mach/mach4.defs: memory_object_get_proxy RPC declaration
* vm/memory_object_proxy.c: memory_object_get_proxy implementation
---
include/mach/mach4.defs | 10
Here you go
On Mon, Nov 1, 2021 at 12:32 PM Joan Lledó wrote:
> +kern_return_t
> +memory_object_get_proxy (task_t task, const vm_offset_t address,
> +vm_prot_t max_protection, vm_offset_t len,
> +ipc_port_t *port)
> +{
> + kern_return_t err;
Super minor nitpic
On Mon, Nov 1, 2021 at 12:33 PM Joan Lledó wrote:
> Thanks for your explanations, it makes sense but there's still one thing I
> don't understand: if memory_object_create_proxy() is the owner of the pager
> it receives as parameter, and the caller doesn't care about releasing it,
> then where i
Hi,
El 30/10/21 a les 14:06, Sergey Bugaev ha escrit:
> I hope this makes sense; I'd be happy to expand if not.
Thanks for your explanations, it makes sense but there's still one thing I
don't understand: if memory_object_create_proxy() is the owner of the pager it
receives as parameter, and th
From: Joan Lledó
To get a proxy to the region a given address belongs to,
with protection and range limited to the region ones.
* include/mach/mach4.defs: memory_object_get_proxy RPC declaration
* vm/memory_object_proxy.c: memory_object_get_proxy implementation
---
include/mach/mach4.defs | 10
15 matches
Mail list logo
