Quoting Samuel Thibault (2015-07-08 18:22:56)
Justus Winter, le Wed 08 Jul 2015 16:22:28 +0200, a écrit :
Alternatively, you could re-purpose the existing RPC `vm_wire',
changing the type of its first argument from `host_priv_t' to `host_t'
(this is backwards compatible as the privileged
Hi :)
Quoting Samuel Thibault (2015-07-08 15:55:33)
I have implemented a start of support for calling mlock() in a non-root
process, which I have attached.
Sweet. You talked about that in your FOSDEM talk, right? Ever since
I thought that managing this in userspace is the better solution,
Hello,
Justus Winter, le Wed 08 Jul 2015 16:22:28 +0200, a écrit :
You talked about that in your FOSDEM talk, right?
Yes, although since I hadn't had any look at it at the time, I hadn't
realized that passing host==NULL wasn't an option (since we need a port
to make the RPC on anyway).
Ever
On Wed, Jul 08, 2015 at 04:32:36PM +0200, Samuel Thibault wrote:
Isn't a per-process limit rather pointless? I thought Linux limit is
per-user.
On Linux it's per process too, changing ulimit -l in a process won't
affect another process.
The issue with mlocked memory is mostly about
Justus Winter, le Wed 08 Jul 2015 16:22:28 +0200, a écrit :
Alternatively, you could re-purpose the existing RPC `vm_wire',
changing the type of its first argument from `host_priv_t' to `host_t'
(this is backwards compatible as the privileged host control port is
also a host port), and
Samuel Thibault, le Wed 08 Jul 2015 18:22:56 +0200, a écrit :
Justus Winter, le Wed 08 Jul 2015 16:22:28 +0200, a écrit :
Alternatively, you could re-purpose the existing RPC `vm_wire',
changing the type of its first argument from `host_priv_t' to `host_t'
(this is backwards compatible as
