conffile, smm, puffinplc and libraries (was: Modbus/tcp works on the lplc repository)

J

Thread Starter

Jiri Baum

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
Linu[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M

Mario J. R. de Sousa

Jiri Baum wrote:

> 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...
>

OK. We have enough to do at the moment...


> 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...

Then why not use the init itself? Why must we re-write a similar program?


> It may be useful to be able to do the startup and shutdown manually,
> running the pieces separately.

Do you mean different modules when you say pieces? In that case you can. Start them up as we are already doing right now; from the command line.

If you mean start up all the modules independently of seting up the plc resources, then you have a point. We might give it another command line option instead of -g.

>
> 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.

I think they are related. Each is a step in the two step process of starting up the plc.

But let's not quible over a detail. It is very simple to cut the code up into several small programs... The code for each of the command line options is written in a separate function...


> > 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.

Yep, I would like to have a program called puffinplc. But wouldn't having different names for the code (.c) and binary files cause confusion? What is the advantage of keeping them different?


> > 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.

Yes. I completely agree. But it might serve as an incentive to making them clean? I don't know... It's the first time I participate on a open sorce
project...


> 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...
>

Are you thinking along the lines of

/libs for miscelaneous libraries
/plc for plc_lib.c and plc.h
/plc/smm for smm.h, smm_lib.c, ...
/plc/conffile for conffile.h, ...
/plc/log for log.h, ...
/plc/synch for future synch.h, ...

I would surely like the above structure. Do you have something else in mind?


Mario.


--
----------------------------------------------------------------------------
Mario J. R. de Sousa [email protected]
----------------------------------------------------------------------------

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
> > 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.

Mario de Sousa:
> > > 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.

Jiri Baum:
> > 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...

Mario de Sousa:
> Then why not use the init itself? Why must we re-write a similar program?

1) init(8) has some things that are specific to being process number one, invoked by the boot process, and being the only init running.

2) we'll probably want some special functionality eventually or even immediately - eg handling of the "quit" point.

> > It may be useful to be able to do the startup and shutdown manually,
> > running the pieces separately.

> Do you mean different modules when you say pieces? In that case you can.
> Start them up as we are already doing right now; from the command line.

> If you mean start up all the modules independently of seting up the plc
> resources, then you have a point. We might give it another command line
> option instead of -g.

Both, really.

> > 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.

> I think they are related. Each is a step in the two step process of
> starting up the plc.

The launcher actually runs throughout the lifetime of the PLC, handling both startup and shutdown, logging any modules that die etc.

To some extent I have this vague feeling whether the smm-mgr, having setup the smm, isn't in some funny state that we'll have to keep worrying about.

> > > 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.

> Yep, I would like to have a program called puffinplc. But wouldn't having
> different names for the code (.c) and binary files cause confusion? What
> is the advantage of keeping them different?

Just that renaming existing files is a pain in CVS. Changing the binary name is just a couple of words in the Makefile.

> > > 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.

> Yes. I completely agree. But it might serve as an incentive to making
> them clean? I don't know...

Nor do I... Probably depends on the individual file.

> > 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...

> Are you thinking along the lines of

> /libs for miscelaneous libraries
> /plc for plc_lib.c and plc.h
> /plc/smm for smm.h, smm_lib.c, ...
> /plc/conffile for conffile.h, ...
> /plc/log for log.h, ...
> /plc/synch for future synch.h, ...

> I would surely like the above structure. Do you have something else in mind?

I was thinking:
/lib/misc for miscelaneous libraries
/lib for plc_lib.c, plc.h and linuxplc.a (or puffinplc.a)
/smm for smm.h, smm_lib.c, ... (leave it where it is, or /lib/smm)
/lib/conffile for conffile.h, ...
/lib/log for log.h, ...
/lib/synch for future synch.h, ...

Obviously, there's no hurry for this.

Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World! Step 1 - bid for SMOFcon

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

Mario de Sousa

> > Are you thinking along the lines of
>
> > /libs for miscelaneous libraries
> > /plc for plc_lib.c and plc.h
> > /plc/smm for smm.h, smm_lib.c, ...
> > /plc/conffile for conffile.h, ...
> > /plc/log for log.h, ...
> > /plc/synch for future synch.h, ...
>
> > I would surely like the above structure. Do you have something else in mind?
>
> I was thinking:
> /lib/misc for miscelaneous libraries
> /lib for plc_lib.c, plc.h and linuxplc.a (or puffinplc.a)
> /smm for smm.h, smm_lib.c, ... (leave it where it is, or /lib/smm)
> /lib/conffile for conffile.h, ...
> /lib/log for log.h, ...
> /lib/synch for future synch.h, ...
>
> Obviously, there's no hurry for this.


OK. I agree with the above, as long as its /lib/smm and not /smm.

I am doing a few misc changes to the code. Could you please wait untill I have committed them before you go ahead with the changes?

Thanks,

Mario.

----------------------------------------------------------------------------
Mario J. R. de Sousa [email protected]
----------------------------------------------------------------------------

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Thread starter Similar threads Forum Replies Date
M LinuxPLC Project 0
M LinuxPLC Project 0
J LinuxPLC Project 0
M LinuxPLC Project 1
M LinuxPLC Project 3
Top