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. 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. -- John Kasunich jmkasun...@fastmail.fm ------------------------------------------------------------------------------ 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
