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 since I thought that managing this in userspace is the better > solution, Well, the actual enforcement has to be done where default paging happens, otherwise it'd be a security issue. > > I had to introduce a newer RPC since the existing vm_wire RPC is > > done on the privileged host port. > > 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 changing the behavior slightly depending on > whether the user passed the priv port or a normal host port. Ah, right. > > It for now allows 64KiB mlocked memory per task (the default Linux > > value). > > 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 eating non-pageable memory. Creating processes already eats non-pageable memory anyway, so it doesn't buy much to eat a bit more non-pageable memory per process. > Oh, and why did you chose `mach4.defs' to add a new RPC? I mean, it > doesn't really matter, the Mach API isn't properly grouped into > protocols, and there is just one huge dispatcher, but I thought we put > new definitions into `gnumach.defs'. I don't really know actually. I'd tend to think that mach4.defs is for newer RPCs which make sense on oldish Mach, while gnumach.defs is for GNU-introduced features, but I really don't know the rules. Samuel
