On Mon, 2005-05-23 at 12:23 -0700, Chandra Seetharaman wrote:
> On Mon, May 23, 2005 at 12:11:02PM -0700, Matthew Helsley wrote:
> > On Mon, 2005-05-23 at 09:59 -0700, Chandra Seetharaman wrote:
> > > On Sat, May 21, 2005 at 02:49:42AM -0700, Matthew Helsley wrote:
> > >
> > > Matt,
> > >
> > > This leads to circular dependency... I think the later one is using
> > > options
> > > which is the one that should stay
> > >
> > > chandra
> > <snip>
> > > > config CKRM_RBCE
> > > > tristate "Vanilla Rule-based Classification Engine (RBCE)"
> > > > - depends on CKRM && RCFS_FS
> > > > + depends on CKRM && RCFS_FS && CKRM_CRBCE != y
> >
> > <snip>
> >
> > > > config CKRM_CRBCE
> > > > tristate "Enhanced Rule-based Classification Engine (RBCE)"
> > > > - depends on CKRM && RCFS_FS && DELAY_ACCT
> > > > + depends on CKRM && RCFS_FS && DELAY_ACCT && CKRM_RBCE != y &&
> > > > NET
> > > > default m
> >
> > <snip>
> >
> > I don't think it's circular -- the terms I think you are referring to
> > use != instead of =. Also of note, the values used in the comparisons
> > allow for both being built as modules (CKRM_RBCE == m != y). Lastly, the
> > only part of the depends on line not in the original patch is the NET
> > dependency for CRBCE (since it now uses netlink sockets instead of
> > RCFS).
>
> circular in the sense that CKRM_RBCE depends on CKRM_CRBCE and vice versa.
> but, the fix i was pointing is also there in your list(15/15). So, it is not
> a problem(you can as well get rid of this one).
> >
> > Cheers,
> > -Matt
While there are several config/build bugs that this patch fails to
address I'm still not sure what you're talking about.
Ignoring for the moment the other depends terms and focusing on the
CKRM_*RBCE terms:
> > > > config CKRM_RBCE
> > > > - depends on ...
> > > > + depends on ... && CKRM_CRBCE != y
> > > > config CKRM_CRBCE
> > > > - depends on ...
> > > > + depends on ... && CKRM_RBCE != y
If CRBCE is build into the kernel (y) then RBCE should not be
selectable (and hence built). Conversely, if RBCE is built into the
kernel (y) then CRBCE should not be selectable (and hence built). These
simultaneous equations correctly describe the relationship of the two
config options.
While the resulting config contains circular references they do not
represent circular dependencies.
Furthermore, since they are siblings in the config tree there is no
user-interface reachability bug due to the circular references.
Cheers,
-Matt
-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
ckrm-tech mailing list
https://lists.sourceforge.net/lists/listinfo/ckrm-tech
