[lkml]   [2001]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [kbuild-devel] Why recovering from broken configs is too hard
On Thu, 3 May 2001 12:59:21 -0400, 
"Eric S. Raymond" <> wrote:
>Keith Owens <>:
>> (3) For failing constraints, freeze the guard variables, change
>> the dependent variable to satisfy the constraint then
>> freeze it.
>There's the problem. You don't know which variable(s) are dependent.
>That's not a well-defined notion here. Consider the case that stimulated
>this whole argument:
> (X86 and SMP) implies RTC!=n
>You think you know that RTC is 'dependent', but this is an illusion created
>by the presence of the asymmetrical `implies'. Go look at the hierarchy.
>You'll see what I mean.

On the contrary, I know what the hierarchy says and I also know that
that implies is normally bidirectional. In the case of batch mode,
where you cannot ask the user to solve the violation, I suggest that
CML2 treat implies as unidirectional, but only for this case.

IOW, the order of the constraints (not the hierarchy) and the ordering
of the guard and dependent variables in each constraint are hints by
the rules writer to CML2 about which variables are more important.
Earlier constraints are more important than later ones. Guard
variables are more important that dependent variables.

So when CML2 reaches the end of a batch config run and has a violation
on 'require X86 and SMP implies RTC!=n', X86 and SMP will not be
considered for changing, RTC will be. Using hints from the order of
the constraints reduces the solution space from 3^1957 to 2.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:52    [W:0.108 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site