On 3/3/2014 12:41 PM, John Kasunich wrote: > > On Mon, Mar 3, 2014, at 12:26 PM, John Morris wrote: >> 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. > I would expect that you want even simulated "real-time" threads > to run at a higher priority than say the web browser. > >> 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. > I must admit that I never even considered the latter requirement. > > When the "sim" system was first concieved years ago (by Jeff Epler > if memory serves), it was all about the second requirement. The > need for a RT kernel has always been a major obstacle to casual > playing around with LinuxCNC. > > The first limitation, "cannot drive hardware" was a result of the > implementation. User space code cannot directly execute "inb" > and "outb" instructions. (I believe they get trapped and result > in a whole bunch of messy stuff happening, to decide if this > particular user process is allowed to access hardware. Way > too much crap between the code issuing "outb" and the port > pin changing state. > > >>> - 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. >> > I agree 110% with John. "sudo make setuid" shouldn't be considered > an obstacle. sudo make setcap... is probably more appropriate. These days, we can set individual capabilities rather than handing out root privileges.
Ken > > I'm actually far more interested in the other implications of allowing > different scheduling. Even in sim mode where RT behavior is not > guaranteed, we do promise that if you base thread is 100uS and > your servo thread is 1mS, the base thread will run 10 times between > invocations of the servo thread. I believe that it is important that > faster threads have higher priority, whether running "sim" or not. > > > ------------------------------------------------------------------------------ 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 Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
