Date: Wed, 18 Feb 2009 21:54:30 +0000 From: Bruce Simpson <bms@incunabulum.net> To: "M. Warner Losh" <imp@bsdimp.com> Cc: xcllnt@mac.com, mips@FreeBSD.org, tinderbox@FreeBSD.org, current@FreeBSD.org Subject: Re: [head tinderbox] failure on mips/mips Message-ID: <499C8396.2020000@incunabulum.net> In-Reply-To: <20090218.120514.831271136.imp@bsdimp.com> References: <B23797BE-91FB-4AE1-8370-E77D66ED05B6@mac.com> <20090217.235826.-1697751865.imp@bsdimp.com> <BE046876-F8EF-4269-9CD6-743483EC1869@mac.com> <20090218.120514.831271136.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?499C8396.2020000>