Date: Wed, 29 Jun 2005 13:33:53 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: Stephan Uphoff <ups@tree.com> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, Bruce Evans <bde@zeta.org.au>, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/i386/i386 trap.c src/sys/amd64/amd64 trap.c Message-ID: <20050629203353.GA5667@ns1.xcllnt.net> In-Reply-To: <1120068712.77984.18622.camel@palm> References: <200506252214.j5PMEgip000380@repoman.freebsd.org> <7c65ef6b909f86fa7f5a8aa041773a72@xcllnt.net> <20050627050618.W34733@delplex.bde.org> <1120052829.77984.17793.camel@palm> <b1b2f68bf241cca18df281a369574619@xcllnt.net> <1120068712.77984.18622.camel@palm>
next in thread | previous in thread | raw e-mail | index | archive | help
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@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050629203353.GA5667>