This is the mail archive of the ecos-patches@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: eSCI patch [was Re: Freescale unified driver]


>>>>> "Andrew" == Andrew Lunn <andrew@lunn.ch> writes:

    >> P.S. Note to configtool developers:
    >> suppose we have following expression in some component:
    >> ...
    >> requires (A || B || C)
    >> ...
    >> 
    >> configtool will open dialog with an offer to resolve the
    >> conflict by selecting 1 choice possibly A. Other choices don't
    >> appear in the dialog. For user's convenience, could you
    >> consider offering all choices (for instance 1 selected and
    >> other's unselected)?

    Andrew> I don't know much about this, so its best to assume im
    Andrew> wrong......

    Andrew> I think this is the inference engines limitation, not the
    Andrew> configtool. The configtool will just show what the
    Andrew> inference engine told it. I think the inference engine
    Andrew> will only offer one solution to the configtool and that
    Andrew> solution is generally the simplist. I think the inference
    Andrew> engine can keep looking for other solutions if its first
    Andrew> solution is rejected. So what happens if you reject the
    Andrew> solution with the configtool? Does it offer another
    Andrew> solution?

    Andrew> Offering multiple solutions at once is not easy. How many
    Andrew> solutions should it offer? In your example, if it only
    Andrew> plays with A, B and C, there are 7 solutions. However, it
    Andrew> could be that there are multiple ways for it to enable A,
    Andrew> if A is not a simple on/off control. The tree of solutions
    Andrew> very quickly becomes big.

Mostly correct. The inference engine will in fact look for alternative
solutions and if multiple ones are found it will use a heuristic to
select the most appropriate one. That is the one which "ecosconfig
resolve" will use, and the one presented by the configtool.

At any time a configuration may have multiple conflicts that need to
be resolved. Each preferred solution may involve manipulating several
options. The solutions may overlap or they may conflict with each
other. Trying to present all that to the user in a graphical tool is
going to be just about impossible. Instead it seems more sensible to
keep the suggested solutions simple, allow humans to reject them, and
then manipulate the individual options in whatever way really
addresses the conflicts. The inference engine is always going to be
limited, it has no way of knowing which options are significant for
your application and which options are largely irrelevant.

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]