Re: [ECOS] ecosconfig patch

[Bart Veer <bartv at redhat dot com>]

>>>>> "Patrick" == Patrick Doyle <wpd@delcomsys.com> writes:

    >> I would go further than that and make "-n" a valid option for
    >> all the ecosconfig subcommands, i.e. a --no-update flag that
    >> suppresses any modifications to the file system. That would be
    >> somewhat similar to cvs -n. A possible patch to implement this
    >> is at the bottom.

    Patrick> Thanks... That is a much better solution than the one I
    Patrick> was proposing. I'll give the patch a try sometime in the
    Patrick> next week or so. Thanks for the credit in the ChangeLog
    Patrick> :-).

I have checked in the changes so they should appear in the next
anoncvs update.

    Patrick> Your discussion about modifying the import/export
    Patrick> behavior raises a whole bunch of interesting points, a
    Patrick> few of which I may have uncovered myself as I continued
    Patrick> to dig deeper. I had gotten just far enough in to know
    Patrick> that I was over my head and should probably check in with
    Patrick> higher authorities before proceeding. If I were to have
    Patrick> some time to look into this, where would you prefer that
    Patrick> I start? (I would not be insulted at all if you
    Patrick> "prefered" that I not start at all, because of all of the
    Patrick> complications that you raised, and because of the lack of
    Patrick> ability to commit to certain amount of time to work on
    Patrick> this).

    Patrick> I had not realized that there would be a backwards
    Patrick> compatible way to add a new command (such as
    Patrick> "remove_package") to savefiles,

In theory it is possible to add new commands to eCos savefiles without
forcing everybody to upgrade to newer tools. In practice this
functionality has never been tested...

    Patrick> but knowing that is possible, my first thought would be
    Patrick> to add such a command, modify the "export" capability to
    Patrick> list (in the savefile) the removed packages the same way
    Patrick> that the "check" capability does, and to modify the
    Patrick> "import" capability to remove the packages thus listed.
    Patrick> Even if I didn't modify the "export" capability,
    Patrick> "removed_package" commands could be incorporated into
    Patrick> hand-edited .ecm files as you pointed out.

    Patrick> It seems that you have some objections to this (perhaps
    Patrick> because it will never work), or, at least, a desire to
    Patrick> see it done "correctly" rather than "expediently". So, I
    Patrick> welcome your comments on this plan.

I must admit that I am not particularly keen on this approach.

1) inside libcdl there is not really any specific "export" or "import"
   code. Instead that functionality is implemented as special cases of
   the savefile code, and there is no easy way to isolate things.
   So any implementation along these lines is likely to involve
   remove_package commands appearing inside ordinary ecos.ecc
   savefiles, which makes little sense to me.

2) automatically figuring out which packages have been removed is
   going to be both difficult and expensive. So generating
   "remove_package" commands when outputting a savefile is not
   a good idea.

   However, if hand-edited .ecm files are acceptable for now then
   the work required would be along the following lines:

     CdlConfigurationBody::initialize_savefile_support()
         register a new sub-command cdl_remove_package

     CdlConfigurationBody::
         add a new routine savefile_handle_remove_package() which will
         be invoked when reading in a savefile and which will delete a
         loadable from the current toplevel.

     CdlToplevelBody::
         up the savefile_version number to 2

   This should suffice to have "cdl_remove_package" appear as one of
   the valid cdl_configuration sub-commands listed at the top of new
   savefiles, and if the command is detected appropriate action is
   taken. No generated savefiles will ever contain such commands, but
   they can be inserted by hand at the end of the cdl_configuration
   section of the savefile.

   It would also be necessary to check just how well older builds of
   ecosconfig would cope with an updated savefile syntax - in other
   words, how well the existing handle_unsupported() functionality
   works in practice.

3) fundamentally messing about with savefile syntax is still the wrong
   way to address the problems. The correct solution is to provide
   script-level access to the configuration data. Such functionality
   would address not just the issues that started this discussion but
   would have a great many other uses as well. However doing anything
   along such lines requires understanding an awful lot about libcdl
   internals and the underlying design goals. It would also involve a
   considerable amount of work. I confess that I would be
   uncomfortable about anybody else attempting this.

Bart