EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  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  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Linux and EPICS threads
From: Andrew Johnson <[email protected]>
To: Mark Rivers <[email protected]>
Cc: [email protected]
Date: Wed, 30 Jul 2003 09:58:17 -0500
Mark Rivers wrote:
I am writing device support on Linux for a parallel port device.  To
talk to the parallel port I use iopl(3) to set the I/O privilege level
of the task, and inb() and outb() to write to the I/O ports.  This
works fine before iocInit.  After iocInit the code is running in a new
epicsThread, and I find that it has "forgotten" the privilege level,
and that I need to call iopl(3) again.  This is very inconvenient,
because the new thread should not even need to know what kind of device
it is talking to.

You will need to worry about more than one thread - each different scan period has its own thread, so it just takes the user changing the SCAN field of the record for your code to have to call iopl(3) yet again, and if it's set to Process Passive then there are several other tasks that might be used depending on how the processing is initiated.


Is this the correct behavior, and is there a way to change it?  I
thought that the the ioc was running as a single task in which all
threads should have the same privileges.  Is there a way to make the
new threads inherit the privileges from the parent?

A task is not the same as a process, especially on Linux. The IOC is running in the context of a single process, but with multiple threads. On Linux, threads are implemented in the kernel as processes that share the same address space and various other characteristics with each other - what gets shared can be selected if you are working at the right level.


However it seems from what Odagiri-san said that there is no way to copy that privilege information when creating a new thread. Therefore I suspect you may be stuck with having to write code in your device support that calls iopl(3) every time it processes; alternatively you might try installing a sigaction() handler for SIGSEGV that calls iopl(3) if your inb()/outb() calls cause a SEGFAULT. However I'm not sure whether signal handlers are thread or process-specific, so you might be forced to set up the signal handler every time your code was entered, which is probably no quicker than the iopl(3) call.

Ah, here's another though that should help - EPICS provides per-thread variables in its OSI layer; you could check the value of a thread variable to see whether you've done the iopl(3) call in this thread yet, and only call it if not.

HTH,

- Andrew
--
There are 10 types of people in the world:
Those who understand binary, and those who don't.


References:
Linux and EPICS threads Mark Rivers

Navigate by Date:
Prev: OMS VME58 card and user definable I/O Rok Sabjan
Next: RE: Linux and EPICS threads Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Linux and EPICS threads Mark Rivers
Next: RE: Linux and EPICS threads Jun-ichi Odagiri
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·