From owner-freebsd-threads@FreeBSD.ORG Sat Jun 28 10:54:37 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 603CA37B401; Sat, 28 Jun 2003 10:54:37 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 719434402B; Sat, 28 Jun 2003 10:54:36 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h5SHsaDZ044066; Sat, 28 Jun 2003 10:54:36 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h5SHsasi001125; Sat, 28 Jun 2003 10:54:36 -0700 (PDT) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h5SHsa3p001124; Sat, 28 Jun 2003 10:54:36 -0700 (PDT) Date: Sat, 28 Jun 2003 10:54:36 -0700 From: Marcel Moolenaar To: deischen@freebsd.org Message-ID: <20030628175436.GA1071@dhcp01.pn.xcllnt.net> References: <20030628153032.GA577@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i cc: threads@freebsd.org Subject: Re: KSE: fuword/suword bugs on ia64 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2003 17:54:37 -0000 On Sat, Jun 28, 2003 at 12:20:03PM -0400, Daniel Eischen wrote: > > > > I was thinking about using long. fuword/suword is defined in terms > > of long, so technically it's a bug to have them operate on int. But > > using long will yield 64-bit fields on 64-bit platforms, and it may > > just be a waste of space. Although internal alignment and padding > > may already take up as much space (tm_flags, km_version, km_flags > > are examples of this). > > The mailboxes are not that big (with the exception of the > thread mailbox due to ucontext), so a few extra bytes isn't > going to hurt userland. Perhaps the copyin/copyout's in > the kernel is what you're worried about? Not really. It's just that I like to be able to defend the size expansion when an alternative exists that does not increase the size. > > I'm divided on the issue. I prefer using long for it being the best > > native type, but don't like the immediate consequence of it being > > too variable for use in interface types (take for example the 64-bit > > long on i386 that bde is playing with). With the patch I favored > > the fixed width property on uint32_t. > > You can use uint32_t for now as a quick fix. Perhaps > we should restructure the mailboxen a bit as a longer > term fix. David just added siginfo to the thread > mailbox, so that's another MD structure. Sounds good. Note that on ia64 ucontext_t has 16-byte alignment. Having the fields reordered definitely helps the overall density. BTW: putting tm_context at the end is a good idea. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net