From owner-cvs-all Thu Feb 22 22:48:27 2001 Delivered-To: cvs-all@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id D77F537B6EE; Thu, 22 Feb 2001 22:48:16 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id RAA28232; Fri, 23 Feb 2001 17:48:12 +1100 Date: Fri, 23 Feb 2001 17:39:43 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: John Baldwin Cc: Doug Rabson , cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/alpha/alpha swtch.s In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 22 Feb 2001, John Baldwin wrote: > I've thought about doing that, yes. If you want, I can stick it on my todo > list. Also, I have managed to make userret() and ast() (modulo a few commits > coming up in the next 15 minutes or so) the same across all architectures. > Do you think that given that it would be feasible to move those two functions > to sys/kern/subr_trap.c and let them be MI? I'm not sure that ast() should be MI. It was in hardware on vaxes. > Also, as a sidenote, I think that addupc_task() should take a uniptr_t, not a > uint64_t as its second argument.. Nah, uniptr_t (sic) only exists on vaxes where all types are the same :-). I think it should take a register_t or uintfptr_t. uintptr_t is only required to work for object pointers. Instruction pointer values in trap frames aren't even C pointers. They normally (should) have type register_t. However, the parts of the profiling code that I cleaned up used uintfptr_t or intfptr_t for representing instruction pointer values. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message