7 Jan
2005
7 Jan
'05
5:20 p.m.
On Fri, Jan 07, 2005 at 03:55:12PM -0500, Lee Revell wrote:
Feh. The RT scheduling class issue is orthogonal. Addressing mlock and
scheduling class at once (and nothing else) is actually an ugliness of
your LSM approach as there are folks who want mlock and not RT.
--
Mathematics is the supreme nostalgia of our time.
On Fri, 2005-01-07 at 12:46 -0800, Matt Mackall
wrote:
My way simply proves that existing userspace methods have not been
exhausted. It's not impossible as was claimed and cleaner methods or
nicely wrapped variants of the above probably exist. And yes, doing
ugly things in userspace is preferable to adding application-specific
baggage to the kernel.
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.
Christ, what a nightmare! Since when does "obviously doable" mean it's
a good idea? Please, reread your above statements, then go back and
look at the realtime LSM patch (it's less than 200 lines), and tell me
again that your way is more secure. As has been
pointed out, an rlimit solution exists now as well.
Wrong, as was said repeatedly, rlimits only help with mlock! Have you
even been reading the thread?