On 03/02/2014 10:52 AM, Michael Haberler wrote: > > 5. The RT-PREEMPT RTAPI code which I imported from Michael Büsch uses > normal Posix threads. It uses the sched_setscheduler(..SCHED_FIFO..) > call to set the desired scheduling policiy. See man 2 > sched_setscheduler. This system call requires elevated privileges. > Except for this system call, the same code qualifies for 'sim' (= > nonRT Posix).
sched_setscheduler() is called in this function: http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=src/rtapi/rt-preempt.c;h=1bb79f285683b9f6ec20ae653719428554eb9f88;hb=refs/heads/unified-build-candidate-3#l316 I guessed that sched_setscheduler() requires elevated privs not because of the SCHED_FIFO policy, but because schedp.sched_priority is set higher than 0. The man page for sched_setscheduler() says, "SCHED_FIFO can be used only with static priorities higher than 0." If that's a hard restriction, then special privs are needed. If it were possible to set SCHED_FIFO with the fast thread prio 0 (no special privs needed), and other thread prio relatively lower, it might achieve the same effect. This could be implemented by changing the definition of the PRIO_HIGHEST macro for POSIX threads to 0 in rtapi/rt-preempt.h. Otherwise, setuid binaries may be avoided for posix and rt-preempt flavors by granting elevated rtprio, cpu and nice limits; see man 5 limits.conf. Of course elevated privs are required to install e.g. /etc/security/limits.d/realtime.conf, so somewhere, someone will need elevated access. > 7. Depending on whom you ask, you get different definitions of what > 'sim' actually means. Some say it means 'cannot drive hardware', some > say it means 'does not need an RT kernel', some mean it to say 'needs > no sudo make setuid step'. The above discussion relates to the latter requirement. > - do we use elevated privileges for the posix flavor binary, and > obtain the desired behavior I'm in favor of this. What sort of person might want to run LinuxCNC in 'sim' mode, and requires no elevated privileges? This person would be building by hand (packages will include setuid binaries and limit.d configs), and using an OS that is locked down. Thanks to cheap hardware and free GNU/Linux OSs, this last condition is so easy to work around that it hardly seems worth considering. If there really is some exotic case that's worth putting effort into, it would only take a day to resurrect the old pth threads and integrate them into the Unified Build. John ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
