Re: [ECOS] Re: Bug in crc32 routine?

[Bart Veer <bartv at ecoscentric dot com>]

>>>>> "Jifl" == Jonathan Larmour <jifl@eCosCentric.com> writes:

    Jifl> One thing I'm concerned about though is that the "default"
    Jifl> requirements of the eth driver include a package that is not
    Jifl> included by default. It shows up two long-standing CDL
    Jifl> issues:

    Jifl> - only hardware packages can be listed in ecos.db targets
    Jifl> - there is no way for the user to request automatically loading required 
    Jifl> packages not currently in the config

    Jifl> the former would be easy to fix, but would be a band-aid for
    Jifl> the latter. Bart's on holiday for a week, but I'd be
    Jifl> interested in his feedback. A bugzilla bug should probably
    Jifl> be submitted to track this (depending on what the correct
    Jifl> value of "this" is ;-)).

Autoloading via CDL is something I have considered in the past. The
syntax would be something like:

    requires -autoload CYGPKG_CRC

Basically -autoload would instruct the inference engine to load
additional packages if necessary, or possibly unload a package for
something like

    requires -autoload !CYGPKG_CRC

There are some obvious uses for this sort of functionality. At the
libcdl level an initial implementation should be relatively
straightforward, pretty much all the necessary functionality is
already in place. But there are also disadvantages:

1) in the past the inference engine has not made such major changes
   to the configuration. Now it would be doing an awful lot more work
   without explicit user permission (at least, in command line mode).
   Or we could allow the users to decide whether or not the inference
   engine is allowed to make such changes automatically, but that
   adds yet more complexity to the user interface.

2) the user could explicitly unload a package and then the inference
   engine could just reload it. Unloading a package corresponds to a
   user_value so the inference engine should not override it. But
   there is no obvious place to store this user_value, it is not
   associated with any particular option. Instead the information
   would need to be stored with the configuration as a whole, with
   appropriate entries in the savefile etc. Suddenly the libcdl
   changes become significant.

3) the GUI tool(s) might need major work. IIRC currently the tree view
   only gets a major update if the user has invoked a dialog that
   could cause packages to be loaded or unloaded. Now the tree view
   might need an update every time the inference engine has run.

By all means file a bugzilla report to make sure that this issue does
not get forgotten, but I don't think I'll give it a particularly high
priority. 

Bart