From owner-cvs-src@FreeBSD.ORG Wed Jun 29 20:33:56 2005 Return-Path: X-Original-To: cvs-src@freebsd.org Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 05E4E16A41C; Wed, 29 Jun 2005 20:33:56 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA6F443D4C; Wed, 29 Jun 2005 20:33:55 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (localhost.xcllnt.net [127.0.0.1]) by ns1.xcllnt.net (8.13.3/8.13.3) with ESMTP id j5TKXs38005877; Wed, 29 Jun 2005 13:33:54 -0700 (PDT) (envelope-from marcel@ns1.xcllnt.net) Received: (from marcel@localhost) by ns1.xcllnt.net (8.13.3/8.13.3/Submit) id j5TKXrB5005876; Wed, 29 Jun 2005 13:33:53 -0700 (PDT) (envelope-from marcel) Date: Wed, 29 Jun 2005 13:33:53 -0700 From: Marcel Moolenaar To: Stephan Uphoff Message-ID: <20050629203353.GA5667@ns1.xcllnt.net> References: <200506252214.j5PMEgip000380@repoman.freebsd.org> <7c65ef6b909f86fa7f5a8aa041773a72@xcllnt.net> <20050627050618.W34733@delplex.bde.org> <1120052829.77984.17793.camel@palm> <1120068712.77984.18622.camel@palm> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1120068712.77984.18622.camel@palm> User-Agent: Mutt/1.4.2.1i Cc: cvs-src@freebsd.org, src-committers@freebsd.org, Bruce Evans , cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/i386/i386 trap.c src/sys/amd64/amd64 trap.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2005 20:33:56 -0000 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