Messages in this thread | | | Date | Fri, 7 Jan 2005 12:46:50 -0800 | From | Matt Mackall <> | Subject | Re: [PATCH] [request for inclusion] Realtime LSM |
| |
On Fri, Jan 07, 2005 at 02:27:26PM -0600, Jack O'Quin wrote: > Matt Mackall <mpm@selenic.com> writes: > > > On Thu, Jan 06, 2005 at 11:54:05PM -0600, Jack O'Quin wrote: > >> Note that sched_setschedule() provides no way to handle the mlock() > >> requirement, which cannot be done from another process. > > > > I'm pretty sure that part can be done by a privileged server handing > > out mlocked shared memory segments. > > If you're "pretty sure", please explain how locking a shared memory > segment prevents the code and stack of the client's realtime thread > from page faulting.
You just map your RT-dependent routine (PIC, of course) into the segment and move your stack pointer into a second segment. I didn't say it was easy, but it's all just bits. There's also the rlimit issue.
Or, going the other way, the client app can pass map handles to the server to bless. Some juggling might be involved but it's obviously doable.
As has been pointed out, an rlimit solution exists now as well.
-- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |