[OCL v1] [git pull] Support loading/unloading of component groups
| Submitted by snrkiwi on Sun, 2010-10-17 16:20 |
Supports loading multiple XML script files into a deployer. Loads the scripts in order, and unloads them in order. This allows, for instance, completely loading system components (e.g. logging) prior to loading application components, and more importantly, completely unloads application components before unloading system components (allowing all application components to log right through to their destruction).
Usage
deployer-macosx --start logging.xml --start application.xml
I did not add the stopComponentsGroup(), etc, new methods to the Orocos interface, so that the user could access them from the taskbrowser. I can do that if people think it is useful. The existing behaviour of stopComponets(), etc, remains the same (stop all components in the correct order).
Tested on macosx and gnulinux.
The following changes since commit 3d460d18156d5360c0ac31fd96b5091ee8e50fe8:
Peter Soetens (1):
doc: reduced font size again in manuals and improved deployment docs.
are available in the git repository at:
git://gitorious.org/~snrkiwi/orocos-toolchain/snrkiwi-ocl.git v1-next-groups
Stephen Roderick (2):
bin: Support deployment of multiple script files
deployment: Support component groups
bin/cdeployer.cpp | 17 ++-
bin/deployer-corba.cpp | 15 ++-
bin/deployer-funcs.cpp | 4 +-
bin/deployer-funcs.hpp | 4 +-
bin/deployer.cpp | 21 +++--
deployment/DeploymentComponent.cpp | 203 +++++++++++++++++++++++++++++-------
deployment/DeploymentComponent.hpp | 66 +++++++++++-
7 files changed, 265 insertions(+), 65 deletions(-)
[OCL v1] [git pull] Support loading/unloading of component group
On Sunday 17 October 2010 18:16:16 S Roderick wrote:
> Supports loading multiple XML script files into a deployer. Loads the
> scripts in order, and unloads them in order. This allows, for instance,
> completely loading system components (e.g. logging) prior to loading
> application components, and more importantly, completely unloads
> application components before unloading system components (allowing all
> application components to log right through to their destruction).
I'm a bit concerned about this contribution. It's not a quality argument, but
a feature argument. Prior to this pull request, I had already voiced that I'm
not eager to add much more features to the deployer's xml mechanism. This
patch kind-of goes frontal into that.
On the other hand, if there's no easier/saner way to boostrap/cleanup logging
with respect to the rest of the application, I can accept it for the sake of
the much desired logging feature.
You don't add the *Group functions to the TaskContext API (with add
method/operation etc). Is there a reason for that ?
I'm still convinced that with an XML + statemachine script solution,
everything could be solved too, in the current state of the code, except for
the problem that we can't automatically start a statemachine from the
deployer.
Peter
[OCL v1] [git pull] Support loading/unloading of component group
On Nov 8, 2010, at 09:10 , Peter Soetens wrote:
> On Sunday 17 October 2010 18:16:16 S Roderick wrote:
>> Supports loading multiple XML script files into a deployer. Loads the
>> scripts in order, and unloads them in order. This allows, for instance,
>> completely loading system components (e.g. logging) prior to loading
>> application components, and more importantly, completely unloads
>> application components before unloading system components (allowing all
>> application components to log right through to their destruction).
>
> I'm a bit concerned about this contribution. It's not a quality argument, but
> a feature argument. Prior to this pull request, I had already voiced that I'm
> not eager to add much more features to the deployer's xml mechanism. This
> patch kind-of goes frontal into that.
>
> On the other hand, if there's no easier/saner way to boostrap/cleanup logging
> with respect to the rest of the application, I can accept it for the sake of
> the much desired logging feature.
I understand the concern, but something like this is the only way that I can see, with the current deployer implementation, to do this. It is a pretty small patchset, though I agree it changes some core deployer code.
> You don't add the *Group functions to the TaskContext API (with add
> method/operation etc). Is there a reason for that ?
I wanted to see what you guys thought. I never use these features, and so had no idea of its affect on other's that do use them.
> I'm still convinced that with an XML + statemachine script solution,
> everything could be solved too, in the current state of the code, except for
> the problem that we can't automatically start a statemachine from the
> deployer.
I needed this here and now, and couldn't wait for planned features to materialize. Didn't Ruben (or maybe Klass?) suggest (or provide) an auto-starting state machine patch, many months ago?
Anyone who starts using the logging (or any other application-oriented services) in a real system will need functionality like this. Regardless of whether it is this implementation or not ...
S
[OCL v1] [git pull] Support loading/unloading of component group
Stephen,
On Mon, Nov 08, 2010 at 03:24:07PM +0100, Stephen Roderick wrote:
> On Nov 8, 2010, at 09:10 , Peter Soetens wrote:
>
> > On Sunday 17 October 2010 18:16:16 S Roderick wrote:
> >> Supports loading multiple XML script files into a deployer. Loads the
> >> scripts in order, and unloads them in order. This allows, for instance,
> >> completely loading system components (e.g. logging) prior to loading
> >> application components, and more importantly, completely unloads
> >> application components before unloading system components (allowing all
> >> application components to log right through to their destruction).
> >
> > I'm a bit concerned about this contribution. It's not a quality argument, but
> > a feature argument. Prior to this pull request, I had already voiced that I'm
> > not eager to add much more features to the deployer's xml mechanism. This
> > patch kind-of goes frontal into that.
> >
> > On the other hand, if there's no easier/saner way to boostrap/cleanup logging
> > with respect to the rest of the application, I can accept it for the sake of
> > the much desired logging feature.
I have a small and still half-baked Lua DSL with the goal to make
deployment easier and among other things can support group
deployment. It only relies on basic deployer operations. Maybe this
could be a way to externalize more complex deployment models? If you
are interested I can clean it up and post it for discussion.
Best regards
Markus
[OCL v1] [git pull] Support loading/unloading of component group
On Nov 9, 2010, at 03:00 , Markus Klotzbuecher wrote:
> Stephen,
>
> On Mon, Nov 08, 2010 at 03:24:07PM +0100, Stephen Roderick wrote:
>> On Nov 8, 2010, at 09:10 , Peter Soetens wrote:
>>
>>> On Sunday 17 October 2010 18:16:16 S Roderick wrote:
>>>> Supports loading multiple XML script files into a deployer. Loads the
>>>> scripts in order, and unloads them in order. This allows, for instance,
>>>> completely loading system components (e.g. logging) prior to loading
>>>> application components, and more importantly, completely unloads
>>>> application components before unloading system components (allowing all
>>>> application components to log right through to their destruction).
>>>
>>> I'm a bit concerned about this contribution. It's not a quality argument, but
>>> a feature argument. Prior to this pull request, I had already voiced that I'm
>>> not eager to add much more features to the deployer's xml mechanism. This
>>> patch kind-of goes frontal into that.
>>>
>>> On the other hand, if there's no easier/saner way to boostrap/cleanup logging
>>> with respect to the rest of the application, I can accept it for the sake of
>>> the much desired logging feature.
>
> I have a small and still half-baked Lua DSL with the goal to make
> deployment easier and among other things can support group
> deployment. It only relies on basic deployer operations. Maybe this
> could be a way to externalize more complex deployment models? If you
> are interested I can clean it up and post it for discussion.
>
> Best regards
> Markus
You understand my concern when you say "half-baked" ... Also, the Lua support is so new that I'm not ready to pull that into any kind of production environment. Lastly, I'm stuck with v1 for some months to come, so unless you plan on backporting Lua ...
I'm definitely interested down the track, but for right now, I'm very happy with what we've got in these patches. They work, the concept is simple, and it is a working solution available now.
Whether these patches make it into upstream or not, we will still have to tackle this problem for v2 in general.
S
[OCL v1] [git pull] Support loading/unloading of component group
On Tue, Nov 09, 2010 at 01:24:15PM +0100, Stephen Roderick wrote:
> On Nov 9, 2010, at 03:00 , Markus Klotzbuecher wrote:
>
> > Stephen,
> >
> > On Mon, Nov 08, 2010 at 03:24:07PM +0100, Stephen Roderick wrote:
> >> On Nov 8, 2010, at 09:10 , Peter Soetens wrote:
> >>
> >>> On Sunday 17 October 2010 18:16:16 S Roderick wrote:
> >>>> Supports loading multiple XML script files into a deployer. Loads the
> >>>> scripts in order, and unloads them in order. This allows, for instance,
> >>>> completely loading system components (e.g. logging) prior to loading
> >>>> application components, and more importantly, completely unloads
> >>>> application components before unloading system components (allowing all
> >>>> application components to log right through to their destruction).
> >>>
> >>> I'm a bit concerned about this contribution. It's not a quality argument, but
> >>> a feature argument. Prior to this pull request, I had already voiced that I'm
> >>> not eager to add much more features to the deployer's xml mechanism. This
> >>> patch kind-of goes frontal into that.
> >>>
> >>> On the other hand, if there's no easier/saner way to boostrap/cleanup logging
> >>> with respect to the rest of the application, I can accept it for the sake of
> >>> the much desired logging feature.
> >
> > I have a small and still half-baked Lua DSL with the goal to make
> > deployment easier and among other things can support group
> > deployment. It only relies on basic deployer operations. Maybe this
> > could be a way to externalize more complex deployment models? If you
> > are interested I can clean it up and post it for discussion.
> >
> > Best regards
> > Markus
>
> You understand my concern when you say "half-baked" ... Also, the
I understand perfectly :-)
> Lua support is so new that I'm not ready to pull that into any kind
> of production environment. Lastly, I'm stuck with v1 for some months
> to come, so unless you plan on backporting Lua ...
Unfortunately no... I prefer to put all efforts into stabilizing v2
right now...
> I'm definitely interested down the track, but for right now, I'm
> very happy with what we've got in these patches. They work, the
> concept is simple, and it is a working solution available now.
Yes. And its wise not to change to many things at once.
> Whether these patches make it into upstream or not, we will still
> have to tackle this problem for v2 in general.
Good. Then I'll package this up when I get around to it and ask for
feedback.
Best regards
Markus
[OCL v1] [git pull] Support loading/unloading of component group
On Tue, 9 Nov 2010, Markus Klotzbuecher wrote:
> Stephen,
>
> On Mon, Nov 08, 2010 at 03:24:07PM +0100, Stephen Roderick wrote:
>> On Nov 8, 2010, at 09:10 , Peter Soetens wrote:
>>
>>> On Sunday 17 October 2010 18:16:16 S Roderick wrote:
>>>> Supports loading multiple XML script files into a deployer. Loads the
>>>> scripts in order, and unloads them in order. This allows, for instance,
>>>> completely loading system components (e.g. logging) prior to loading
>>>> application components, and more importantly, completely unloads
>>>> application components before unloading system components (allowing all
>>>> application components to log right through to their destruction).
>>>
>>> I'm a bit concerned about this contribution. It's not a quality argument, but
>>> a feature argument. Prior to this pull request, I had already voiced that I'm
>>> not eager to add much more features to the deployer's xml mechanism. This
>>> patch kind-of goes frontal into that.
>>>
>>> On the other hand, if there's no easier/saner way to boostrap/cleanup logging
>>> with respect to the rest of the application, I can accept it for the sake of
>>> the much desired logging feature.
>
> I have a small and still half-baked Lua DSL with the goal to make
> deployment easier and among other things can support group
> deployment. It only relies on basic deployer operations. Maybe this
> could be a way to externalize more complex deployment models? If you
> are interested I can clean it up and post it for discussion.
This is a good idea. It would be even better if you could make a short
comparison with how, for example, the Linux kernel solves this problem of
bootstrapping itself.
Herman
[OCL v1] [git pull] Support loading/unloading of component group
On Tue, Nov 09, 2010 at 09:18:50AM +0100, Herman Bruyninckx wrote:
> On Tue, 9 Nov 2010, Markus Klotzbuecher wrote:
>
> > Stephen,
> >
> > On Mon, Nov 08, 2010 at 03:24:07PM +0100, Stephen Roderick wrote:
> >> On Nov 8, 2010, at 09:10 , Peter Soetens wrote:
> >>
> >>> On Sunday 17 October 2010 18:16:16 S Roderick wrote:
> >>>> Supports loading multiple XML script files into a deployer. Loads the
> >>>> scripts in order, and unloads them in order. This allows, for instance,
> >>>> completely loading system components (e.g. logging) prior to loading
> >>>> application components, and more importantly, completely unloads
> >>>> application components before unloading system components (allowing all
> >>>> application components to log right through to their destruction).
> >>>
> >>> I'm a bit concerned about this contribution. It's not a quality argument, but
> >>> a feature argument. Prior to this pull request, I had already voiced that I'm
> >>> not eager to add much more features to the deployer's xml mechanism. This
> >>> patch kind-of goes frontal into that.
> >>>
> >>> On the other hand, if there's no easier/saner way to boostrap/cleanup logging
> >>> with respect to the rest of the application, I can accept it for the sake of
> >>> the much desired logging feature.
> >
> > I have a small and still half-baked Lua DSL with the goal to make
> > deployment easier and among other things can support group
> > deployment. It only relies on basic deployer operations. Maybe this
> > could be a way to externalize more complex deployment models? If you
> > are interested I can clean it up and post it for discussion.
>
> This is a good idea. It would be even better if you could make a short
> comparison with how, for example, the Linux kernel solves this problem of
> bootstrapping itself.
I'm not sure which relationship you mean here? OS bootstrapping is
challenging because the system has to configure and enable certain
features like the MMU and continue to function at the same time. In
deploying RTT we do have ordering constraints but we don't need to
bootstrap in the sense that we start with a limited set of
functionality.
Markus
[OCL v1] [git pull] Support loading/unloading of component group
On Nov 9, 2010, at 03:18 , Herman Bruyninckx wrote:
> On Tue, 9 Nov 2010, Markus Klotzbuecher wrote:
>
>> Stephen,
>>
>> On Mon, Nov 08, 2010 at 03:24:07PM +0100, Stephen Roderick wrote:
>>> On Nov 8, 2010, at 09:10 , Peter Soetens wrote:
>>>
>>>> On Sunday 17 October 2010 18:16:16 S Roderick wrote:
>>>>> Supports loading multiple XML script files into a deployer. Loads the
>>>>> scripts in order, and unloads them in order. This allows, for instance,
>>>>> completely loading system components (e.g. logging) prior to loading
>>>>> application components, and more importantly, completely unloads
>>>>> application components before unloading system components (allowing all
>>>>> application components to log right through to their destruction).
>>>>
>>>> I'm a bit concerned about this contribution. It's not a quality argument, but
>>>> a feature argument. Prior to this pull request, I had already voiced that I'm
>>>> not eager to add much more features to the deployer's xml mechanism. This
>>>> patch kind-of goes frontal into that.
>>>>
>>>> On the other hand, if there's no easier/saner way to boostrap/cleanup logging
>>>> with respect to the rest of the application, I can accept it for the sake of
>>>> the much desired logging feature.
>>
>> I have a small and still half-baked Lua DSL with the goal to make
>> deployment easier and among other things can support group
>> deployment. It only relies on basic deployer operations. Maybe this
>> could be a way to externalize more complex deployment models? If you
>> are interested I can clean it up and post it for discussion.
>
> This is a good idea. It would be even better if you could make a short
> comparison with how, for example, the Linux kernel solves this problem of
> bootstrapping itself.
>
> Herman
Not sure I'd use the Linux double-kernel load approach as an example to follow ...
S