M
Hello all,
I have been lurking on this list with great interest. Unfortunately I haven't much time at the moment to make any code contributions.
Just like Jiri, I just can't bring myself to like the Great Namer. It's the fact that it needs a running process simply to forward
configuration info to all I/O and logic engines. What happens if this process somehow fails? All I/O and logic engines that have started will
not be affected (assuming they only get configuration info on tsrat-up), but no new I/O and logic engines will be able to start.
Here is my sugestion: put all this configuration info into a separate shared memory area. All processes can have access to this area to get
the configuration info, instead of having to contact a running process.
Possible problems: Acess to the shared memories require knowledge on behalf of all acessing processes of the number of pages and their identification. Since at leats the size of these two areas will need to be configurable, depending on each setup of the LinuxPLC, I suggest a third, small, fixed size, shared memory area with the
configuration of the other two shared memory areas. The ID of this shared memory area will have to be obtained from an environment variable, defaulting to some fixed value if the environment variable does not exist.
Does anybody see any problems with this? Jiri?
Please feel free to ask if I haven't made my ideas clear.
Mario.
Mario J. R. de Sousa
email: [email protected]
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
I have been lurking on this list with great interest. Unfortunately I haven't much time at the moment to make any code contributions.
Just like Jiri, I just can't bring myself to like the Great Namer. It's the fact that it needs a running process simply to forward
configuration info to all I/O and logic engines. What happens if this process somehow fails? All I/O and logic engines that have started will
not be affected (assuming they only get configuration info on tsrat-up), but no new I/O and logic engines will be able to start.
Here is my sugestion: put all this configuration info into a separate shared memory area. All processes can have access to this area to get
the configuration info, instead of having to contact a running process.
Possible problems: Acess to the shared memories require knowledge on behalf of all acessing processes of the number of pages and their identification. Since at leats the size of these two areas will need to be configurable, depending on each setup of the LinuxPLC, I suggest a third, small, fixed size, shared memory area with the
configuration of the other two shared memory areas. The ID of this shared memory area will have to be obtained from an environment variable, defaulting to some fixed value if the environment variable does not exist.
Does anybody see any problems with this? Jiri?
Please feel free to ask if I haven't made my ideas clear.
Mario.
Mario J. R. de Sousa
email: [email protected]
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
