New smm manager

M

Thread Starter

Mario de Sousa

Hi all,

Like Jiri, I didn't like the idea of a great namer (gn), so I got to hacking the smm code a little.

I have submitted the changes I made to Jiri, but it seems he hasn't much time available to check them out.

Basically, this is what I did:

a) all functions returning void now return an int
0 for success, -1 on error
b) the gn has disappeared. This is replaced by a second shared memory area where the plc configuration is stored.
All modules access the conf. area directly through the smm and confmap (configuration map) managers.
c) The globalmap remains as it was.
d) I have added a whole set of options to the smm-mgr that now allows it to startup and shutdown the plc. It can also dump the configuration data stored in the confmap, and dump it's interpretation of the linuxplc.conf file.
e) I created a very simple test program to test the plc. With it we can set, get, and reset points. The -m option controls the module name with which it will connect to the plc.
f) I added a new plc_init_opt(...) function to the smm.h interface. This function accepts (int argc, char **argv) arguments inside which initialization options can be passed.
If a program (like the test program) passed its command line options to this functions we can control how the plc is initialised using command line options.
The main options allowed are --PLClocal (default behaviour) and --PLCisolate.
--PLCisolate allows the module connecting to the plc to become completely isolated from the globalmap. This protects the globalmap from becoming destroyed by any stray pointer the module program may have. This is accomplished by having a second process (automatically launched) doing the synchronisation between the global and local maps. The module does not attach the globalmap memory area.
--PLClocal has the module attach both the configuration and globalmap memory areas. This is dangerous for poorly tested modules as these may destroy the data in the globalmap un-intentionally through stray pointers. The data may even be related to another module which may then not behave properly.
The code is not very clean. Especially the code used for reading the linuxplc.xonf file. This is just a quick hack to make it usefull. The plc cleans up after itself if all goes well. I still
need to write the cleanup code in case anything goes wrong during initialisation. It shouldn't be too difficult. I have the structure waiting for it. I jus think it would make more sense to put
out the code to see what you all think before I spen any more time hacking out something nobody is interested in.

I don't know what to do with this code. If anybody is interested please suggest a way for me to make it available.


Best regards,


Mario.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
K
> Like Jiri, I didn't like the idea of a great namer (gn), so I got to
> hacking the smm code a little.
[...]
> I don't know what to do with this code. If anybody is interested
> please sugest a way for me to make it available.
>
How about checking it into the CVS? If you don't currently have write privileges to the CVS, send along the file and we'll be glad to check it in.

Ken Crater
[email protected]

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
> > Like Jiri, I didn't like the idea of a great namer (gn), so I got to
> > hacking the smm code a little.
> [...]
> > I don't know what to do with this code. If anybody is interested please
> > sugest a way for me to make it available.

Ken Crater:
> How about checking it into the CVS? If you don't currently have write
> privileges to the CVS,

I think Mario should have write access to the CVS if he wants it - for one thing, I think he's now written more lines on the SMM than me :)

> send along the file and we'll be glad to check it in.

I'll be checking it in - I have the advantage that, since I did most of the changes in the CVS since Mario downloaded the code, I'll rememeber what they were on about...

I'd be doing it right now, but linuxplc.org is off-line at the moment.

Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Hello,

Mario de Sousa:
> I have submitted the changes I made to Jiri, but it seems he hasn't much
> time available to check them out.

Oops, sorry, they *have* been in my inbox longer than they should have been (along with some 900-odd other things).

I'm checking it in now...

> Basically, this is what I did:

> a) all functions returning void now return an int 0 for success, -1 on
> error

Good idea. (I was going to have an error callback, seeing how easily return values are thrown away in C, but having an error return is a good idea anyway. We can have both when we get around to it.)

> b) the gn has disappeared. This is replaced by a second shared memory
> area where the plc configuration is stored. All modules access the conf.
> area directly through the smm and confmap (configuration map) managers.

OK. (I'll probably make a separate post on the Great Namer.)

I've renamed it back to the Great Namer, I hope you don't mind...

> d) I have added a whole set of options to the smm-mgr that now allows it
> to startup and shutdown the plc. It can also dump the configuration data
> stored in the confmap, and dump it's interpretation of the linuxplc.conf
> file.

OK.

> e) I created a very simple test program to test the plc. With it we can
> set, get, and reset points. The -m option controls the module name with
> which it will connect to the plc.

Good.

> f) I added a new plc_init_opt(...) function to the smm.h interface. This
> function accepts (int argc, char **argv) arguments inside which
> initialization options can be passed.

Again, good.

> --PLCisolate allows the module connecting to the plc to become completely
> isolated from the globalmap.

Nice option.

Once again, sorry about making you wait so long - I've been a bit disorganized these last few weeks, with the the project I'm supposed to be
doing falling behind, and as a result I haven't been looking at the linuxPLC at all.

Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
K
Jiri wrote:
>I think Mario should have write access to the CVS if
>he wants it - for one thing, I think he's now written
>more lines on the SMM than me :)

Agreed, however Dan is the one here who has configured the CVS, and he's on vacation till mid next week. Much as I'd love to learn the intricacies of adding users to CVS right now, I think I'll wait till he returns <g>.
Ken

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
I wrote:
> I'm checking it in now...

OK, no I'm not. I can't get through - there seems to be a problem around Control Technology Corporation.

I get as far as control-technology-corporation.WestOrange.cw.net but no further.

>ping linuxplc.org
PING linuxplc.org (208.164.187.3): 56 data bytes
^C
----linuxplc.org PING Statistics----
102 packets transmitted, 0 packets received, 100.0% packet loss
>/usr/sbin/traceroute linuxplc.org
traceroute to linuxplc.org (208.164.187.3), 30 hops max, 38 byte packets
...
8 acr2-serial2-2-0-0.SanFranciscosfd.cw.net (206.24.209.205) 469.675 ms 509.739 ms 529.758 ms
9 corerouter2.SanFrancisco.cw.net (204.70.9.132) 549.885 ms 539.688 ms 590.129 ms
10 corerouter2.WestOrange.cw.net (204.70.9.139) 599.473 ms 599.542 ms 529.946 ms
11 bordercore1.WestOrange.cw.net (166.48.4.1) 659.840 ms 539.649 ms 479.838 ms
12 control-technology-corporation.WestOrange.cw.net (166.48.236.210) 560.058 ms 539.082 ms 599.314 ms
13 * * *
...
30 * * *


I'll check it in as soon as it's back up.

Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Top