From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 21:54:39 2009 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 BF6C3106567D for ; Wed, 18 Feb 2009 21:54:39 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 6219A8FC19 for ; Wed, 18 Feb 2009 21:54:39 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 9996129B032; Wed, 18 Feb 2009 16:54:38 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Wed, 18 Feb 2009 16:54:38 -0500 X-Sasl-enc: dXKtkqfSb1fnZTVFZkGS9ZcHDBV79PODrDElARWeQdY7 1234994078 Received: from empiric.lon.incunabulum.net (unknown [81.168.51.182]) by mail.messagingengine.com (Postfix) with ESMTPSA id 3446A1AD32; Wed, 18 Feb 2009 16:54:33 -0500 (EST) Message-ID: <499C8396.2020000@incunabulum.net> Date: Wed, 18 Feb 2009 21:54:30 +0000 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: "M. Warner Losh" References: <20090217.235826.-1697751865.imp@bsdimp.com> <20090218.120514.831271136.imp@bsdimp.com> In-Reply-To: <20090218.120514.831271136.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: xcllnt@mac.com, mips@FreeBSD.org, tinderbox@FreeBSD.org, current@FreeBSD.org Subject: Re: [head tinderbox] failure on mips/mips 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, 18 Feb 2009 21:54:40 -0000 M. Warner Losh wrote: > ... > : The point being that programmers *do* code with certain > : assumptions and as soon as those assumptions don't hold on > : a platform, you end up worse off. My thoughts for MIPS n32 > : are to make it behave like any "normal" 32-bit strong- > : alignment platform to avoid 1) a large number of runtime > : alignment faults -- which are a bigger performance bottleneck > : than forcing 64-bit integrals to be accessed with 2 32-bit > : accesses > FWIW, Linux use a type-length-value protocol for the netlink routing socket, so alignment issues of this kind are shifted around (forgive the pun). > It also turns out that in this case, a simple (void *) is safe and > causes no issues because that time_t isn't accessed... It does give > one time to pause and think about it. > Yes, the void * cast works around the issue for now, but doesn't offer any guarantees that we are doing the right thing on strict alignment architectures. If the alignment *is* invalid, then we take the hit. cheers BMS