Experimental Physics and
| |||||||||||||||||
|
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.
| ||||||||||||||||
ANJ, 10 Aug 2010 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing · |