1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 <2016> 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 <2016> 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: set-user-id root and EPICS 3.15 |
From: | Till Straumann <[email protected]> |
To: | "J. Lewis Muir" <[email protected]>, [email protected] |
Date: | Fri, 29 Jan 2016 18:00:28 -0800 |
On 01/29/2016 03:04 PM, J. Lewis Muir wrote:
On 1/29/16 3:54 PM, Till Straumann wrote:These would be my arguments: - it doesn't make much sense to use RT scheduling w/o memory locking as this would hurt determinism. Thus, selectively disabling mlockall() is a poor work-around.Hi, Till. True, but I think that just means the toggle is for the wrong thing. It sounds like there should be a toggle for RT, not mlockall. The RT toggle would enable both the RT scheduling and the mlockall.
That's what I suggested as an alternative - if you made it all the way to the bottom of my post ;-). I can see the value of a switch (or envvar) - but that should control the choice of scheduler together with mlock (and maybe even other features - such as priority inheritance - which could be desirable on certain platforms). The semantics should be "run as a RT app yes or no" with the default being "no"...
- the code uses these features (RT scheduling + mlockall) *only* if you give it sufficient privilege to use them. If it has the privileges then the code assumes you want it to use them.This is perhaps the real issue: the code assumes it should use something just because it has sufficient privileges to do so. If I'm understanding things correctly, if I want to run something as root (or with certain capabilities) *without* RT, I can't do it. But a toggle for RT would allow me to do it. Regards, Lewis