From owner-freebsd-current@FreeBSD.ORG Wed Apr 6 01:15:33 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EE59106564A for ; Wed, 6 Apr 2011 01:15:33 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 17DC08FC12 for ; Wed, 6 Apr 2011 01:15:32 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p361FU3G060062 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 5 Apr 2011 18:15:32 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4D9BBED1.3070402@freebsd.org> Date: Tue, 05 Apr 2011 18:16:01 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: kernel thread creation cleanup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 01:15:33 -0000 I was just looking in the thread creation code after most of a decade NOT looking at it.. boy we really need to go through there with a broom.. the cobwebs are getting thick. Like we always call the code to put an upcall, even though we don't have upcalls any more, and we always create an trap frame on the stack even when we are making kernel threads that don't need it, actually, come to think of it DOES fork even need it? (need to go look) and we go through the fork trampoline even when we are doing kthread creation and could just as well go directly to the final function directly. (All of the above on amd64).. May be slighly different on other hardware, though much of it is encoded in MI code so probably not. This came from looking to see if I could somehow munge the stack to convince kgdb to damn well stop at that point (still failed. if anyone has ideas... :-)