J
Mario de Sousa wrote:
> What with all the XML debate going on, I was thinking of creating an
> intermediate API to access the plc config file.
...
> I would like to sugest we keep the existing functions and semantics, but
> change the names of these functions to something like
> plc_conf_get_value(...) , etc...
I think we should wait until we have a bit more experience using the API, then we can design a new one, maybe with different semantics, and have the conffile_*() functions only for backward-compatibility (and gradually retire them).
Changing just the names doesn't seem worth the effort...
Jiri Baum:
> > > > Actually, there needs to be a generic way of starting up a
> > > > linuxPLC, because there'll always be a collection of processes to
> > > > be run, plus setup and shutdown. It shouldn't be a perl script but
> > > > rather a C program that runs according to a section in
> > > > linuxplc.conf
...
> I've been thinking for quite some time of adding this piece of code to
> the smm-mgr but other stough has been coming in the way. The -g command
> line option would first init the common shared memory resources, and then
> launch modules configured in the config file.
I'm not sure if it really belongs in the smm-mgr; I'd have probably made it a separate program, in another directory, that works init(8)-style. Maybe
that's just the small-pieces philosophy...
It may be useful to be able to do the startup and shutdown manually, running the pieces separately.
I would prefer it to be separate. It'll be a big enough program without also handling the SMM setup/takedown, and the two functionalities are not really all that related.
> BTW, I sugest we change the name of the smm-mgr to plc-mgr. What does
> everybody think?
If it handles the startup, then yes, it should be plc-mgr or puffinplc (just change name of the binary, though). If the startup-shutdown process
is separate, then smm-mgr keeps its name and the startup-shutdown process gets the name puffinplc.
I think it should be called "puffinplc", because it'll be the program most people will run to start the LPLC.
> Another sugestion, seeing there are more people producing code now, is
> that we move the utility function files (sin_util.c, sem_util.c, ...) to
> a common directory, so other modules may use them if required.
Yes. I'm not sure if all of them are really clean enough to be generally offered, but certainly there should be a directory for miscellaneous libs.
Maybe even the conffile and logging libraries should be there.
> They can also be used from the smm directory, but I would like to keep
> the public interface to the smm directlory limited to the plc.h file.
If we move the conffile and logging libraries out, then it'll really be the smm.h file that's the public interface to the smm directory - and the libs directory will acquire a mini "plc" library that just has plc_init(), plc_done() and keeps track of the module name.
Maybe I'll do that sometime...
Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World!
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
> What with all the XML debate going on, I was thinking of creating an
> intermediate API to access the plc config file.
...
> I would like to sugest we keep the existing functions and semantics, but
> change the names of these functions to something like
> plc_conf_get_value(...) , etc...
I think we should wait until we have a bit more experience using the API, then we can design a new one, maybe with different semantics, and have the conffile_*() functions only for backward-compatibility (and gradually retire them).
Changing just the names doesn't seem worth the effort...
Jiri Baum:
> > > > Actually, there needs to be a generic way of starting up a
> > > > linuxPLC, because there'll always be a collection of processes to
> > > > be run, plus setup and shutdown. It shouldn't be a perl script but
> > > > rather a C program that runs according to a section in
> > > > linuxplc.conf
...
> I've been thinking for quite some time of adding this piece of code to
> the smm-mgr but other stough has been coming in the way. The -g command
> line option would first init the common shared memory resources, and then
> launch modules configured in the config file.
I'm not sure if it really belongs in the smm-mgr; I'd have probably made it a separate program, in another directory, that works init(8)-style. Maybe
that's just the small-pieces philosophy...
It may be useful to be able to do the startup and shutdown manually, running the pieces separately.
I would prefer it to be separate. It'll be a big enough program without also handling the SMM setup/takedown, and the two functionalities are not really all that related.
> BTW, I sugest we change the name of the smm-mgr to plc-mgr. What does
> everybody think?
If it handles the startup, then yes, it should be plc-mgr or puffinplc (just change name of the binary, though). If the startup-shutdown process
is separate, then smm-mgr keeps its name and the startup-shutdown process gets the name puffinplc.
I think it should be called "puffinplc", because it'll be the program most people will run to start the LPLC.
> Another sugestion, seeing there are more people producing code now, is
> that we move the utility function files (sin_util.c, sem_util.c, ...) to
> a common directory, so other modules may use them if required.
Yes. I'm not sure if all of them are really clean enough to be generally offered, but certainly there should be a directory for miscellaneous libs.
Maybe even the conffile and logging libraries should be there.
> They can also be used from the smm directory, but I would like to keep
> the public interface to the smm directlory limited to the plc.h file.
If we move the conffile and logging libraries out, then it'll really be the smm.h file that's the public interface to the smm directory - and the libs directory will acquire a mini "plc" library that just has plc_init(), plc_done() and keeps track of the module name.
Maybe I'll do that sometime...
Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World!
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc