cvs commit: src/sys/i386/i386 trap.c src/sys/amd64/amd64 trap.c

[Marcel Moolenaar]

On Wed, Jun 29, 2005 at 02:11:53PM -0400, Stephan Uphoff wrote:

> I am all for MI code and callback functions.
> However kdb_trap is only called from MD code.

Renaming the MI function and wrapping it in a MD function called
kdb_trap will not change the elementary fact :-)

> Guaranteeing a certain execution environment for the MI code is all I
> care about. There is no abstraction gained by using MI callbacks on
> entering/exiting the MD kdb trap function.

This is where I have my doubts, because if you can make guarantees
applicable to MI code, you ipso facto say something about the MI
state of the kernel. This logically means that you can use MI code
to establish that *ABSTRACT* state. Consequently: kdb_trap is
inherently MI (as I said before).

For example: The guarantee "interrupts are disabled" is already the
MI abstraction of the MD state that prevents interrupts. As such,
we rightfully have MI interfaces to establish that condition and you
can establish that guarantee with MI code. Consequently: disabling
interrupts in MD code is the wrong thing to do because each platform
will have the same statement duplicated.

So: AFAICT, the brokenness in KDB is not caused by the wrong
abstractions, but by incomplete code. Adding the necessary
callbacks or fleshing out the MI code should be enough to fix
whatever problems we have now.

> This being said I am not religious about it and can use callbacks if you
> feel strongly about this. I just think callbacks would be a bit silly in
> this context.

I'm happy to assume that my perception of "this context" is different
from your perception. If you think I can use a well-placed blow on the
head with a clue bat, feel free to practice your swing. If it turns
out that we would end up with a silly set of *NECESSARY* callbacks,
then I have no problem with changing the flow from MI->MD to MD->MI.

As for religion: I'm religious about abstractions. Because the only
way you can support multiple architectures is by having the right
abstractions. Start off wrong and you'll end up with a bag of kluges
and the unavoidable assumption that "it's the best we can do", which
can only result in the generally accepted misconception that the
problem is too hard to solve.

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel at xcllnt.net