On Wed, 2003-02-19 at 16:39, Louis Zhuang wrote:
> On Wed, 2003-02-19 at 09:08, Rusty Lynch wrote:
> > > > Cool! It is already a truth in my local development machine. I'd like to
> > > > see that... IMHO, I'd like to split more trees, for example,
> > > > original linux-2.5 =======> fi1 ===============||
> > > > || ||===> fi-all
> > > > ||==> kprobes ==> fi2 ===||
> > > >
> > > > fi1 tree is the FITH stuffs independent, fi2 tree is FITH stuffs
> > > > dependent on kprobes, fi-all is only an integrated tree.
> > > >
> > > > - Louis
> >
> > hmmm... What changes would you make on top of the kprobes tree that does
> > not have any dependency on the core fault injection code?
> Oh, you are right. so dependency diagram should be
> original linux-2.5 =======> fi1
> || ||===> fi2
> ||==> kprobes ===========||
>
> >
> > My biggest concern (even with my original suggestion) is that the
> > available fault injection bk trees would be confusing for both the
> > casual observer and developers trying to get involved. I would really
> > like to have only one tree that is _the_ fault injection tree, and then
> > a couple more trees that experiment with some additional code based on
> > external dependencies.
> In fact, "fi1" includes almost all things in FITH, including fi_core,
> kmmio, MMIO interceptor, kirq, fake irq interceptor, code segments,
> testing. Only DR and DBP will be put into . I admit the name is
> confusing... maybe we can change "fi1" to "fi" and change "fi2" to
> "fi-ext"...
lets use "fi" for the main (no external dependencies) bk tree, and
fi-extern for the tree that pulls from fi and kprobes. Hopefully we
only ever have one external tree to pull from.
--rustyl
|
