On Sun, 2003-02-16 at 22:25, Louis Zhuang wrote:
> Dear all,
> I found the current linux kernel had changed debug exception from trap
> gate to interrupt gate. It is the only reason that KMMIO depends on
> Kprobes. Pls take a look at following dependency diagrams:
>
> Original dependency [2.5.44, 2.5.59]
> 2.5<--- KIRQ
> |
> |- Kprobes<--- KMMIO<- Page Fault Interceptor
> |
> |- DBP Interceptor
> |
> |- DR Interceptor
>
> Current dependency [2.5.60, future)
> 2.5<--- KIRQ
> |
> |- KMMIO<--- Page Fault Interceptor
> |
> |- Kprobes<--- DBP Interceptor
> |
> |- DR Interceptor
>
> So my questions are,
> 1. Should we remove Kprobes and DBP/DR from our FITH tree and change
> KMMIO against 2.5.60?
> 2. Should we port Kprobes to 2.5.60 or wait Kprobes team to do it?
> 3. When/How should we make DBP/DR back?
>
> See also http://www.uwsg.iu.edu/hypermail/linux/kernel/0302.1/0081.html
> --
> Yours truly,
> Louis Zhuang
To be honest I am a little torn on which direction is the best
direction. My take on our current situation is:
* I do not think that any code created in this project (core fi
infrastructure/fi components like interceptors/kirq/kmmio) should be
included into the kernel until 2.7 since the current 2.5 work really
should be concentrating on stabilizing for 2.6.
* When it is appropriate to start feeding changes into the kernel, we
will need to have clean bk trees for Linus to pull from. Any code that
still has external dependencies is by definition not ready for Linus to
pull into his tree.
* I like having a common tree for all of us to check our current hacks
into, but it is a pain to keep external dependencies updated.
hmmm... how about we maintain 1 + 2n kernel trees? One tree is a clone
of Linus' 2.5 tree and contains our changes that do not have external
dependencies. For each external dependency we maintain two trees, the
first would be a clone of Linus's tree with the external dependency
changes applied, the second tree is a clone of our linux-2.5 tree with
changes from the external dependencies tree pulled in and then our
changes on top.
It case that was as clear as mud, our bk trees (with the current kprobes
dependency) would look like:
http://linux.bkbits.net:8080/linux-2.5
||
||------------------------------------------------
|| ||
\/(pulls from) ||
bk://fau...@fa.../fi ||
|| \/ (pulls from)
|| bk://fau...@fa.../kprobes
|| ||
|| ||
\/(pulls from) \/(pulls from)
bk://fau...@fa.../fi-kprobes
Using this approach, our fi tree would eventually be the tree that we
ask Linus to pull from, and the I would expect that as soon as kprobes
is accepted in Linus' tree that our work in fi-kprobes would move to our
fi tree and the fi-kprobes and kprobes tree would go away.
This approach would also discourage adding more external dependencies
(which I believe is a "good thing") because it is a lot more work. For
example if kprobes becomes difficult to keep current, then the
fi-kprobes tree would start moving slower. Anyone who feels a strong
need to depend on kpobes (or any other external dependency) would take
on the maintenance of the given external tree.
IMHO this seems like a fairly practical solution. Any thoughts?
--rustyl
|
