From owner-svn-src-all@FreeBSD.ORG Wed Aug 11 13:35:38 2010 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C160106566C for ; Wed, 11 Aug 2010 13:35:38 +0000 (UTC) (envelope-from olli@fromme.com) Received: from haluter.fromme.com (haluter.fromme.com [212.17.241.231]) by mx1.freebsd.org (Postfix) with ESMTP id B9BAC8FC0A for ; Wed, 11 Aug 2010 13:35:37 +0000 (UTC) Received: from haluter.fromme.com (irc_sucks@localhost [127.0.0.1]) by haluter.fromme.com (8.14.3/8.14.3) with ESMTP id o7BDZSDG052432; Wed, 11 Aug 2010 15:35:35 +0200 (CEST) (envelope-from olli@fromme.com) Received: (from olli@localhost) by haluter.fromme.com (8.14.3/8.14.3/Submit) id o7BDZSQs052430; Wed, 11 Aug 2010 15:35:28 +0200 (CEST) (envelope-from olli) From: Oliver Fromme Message-Id: <201008111335.o7BDZSQs052430@haluter.fromme.com> To: des@des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Wed, 11 Aug 2010 15:35:28 +0200 (CEST) In-Reply-To: <86fwylecm1.fsf@ds4.des.no> X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (haluter.fromme.com [127.0.0.1]); Wed, 11 Aug 2010 15:35:36 +0200 (CEST) Cc: src-committers@FreeBSD.org, jilles@stack.nl, svn-src-all@FreeBSD.org, olli@FreeBSD.org, svn-src-head@FreeBSD.org, "M. Warner Losh" Subject: Re: svn commit: r211023 - head/usr.sbin/syslogd X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 13:35:38 -0000 Dag-Erling Smørgrav wrote: > "M. Warner Losh" writes: > > You'll find that a number of structures are potentially already > > allocated with less than required alignment. There's about a dozen > > places in the tree that would start to fail if we did this, or the > > stronger form of __aligned(8). We could add that to the other > > structures, but then we're breaking ABI rules, I think. > > __aligned(4) won't affect struct addrinfo since the sockaddr immediately > follows a socklen_t, which is 32 bits wide and has 32-bit alignment. A > sockaddr_* allocated with malloc() will already be aligned, and so will > a sockaddr_* created on the stack. The only problem is sockaddr_un, > because its size is not a multiple of 4, so if you allocate an array of > sockaddr_un, every other element will be misaligned. I did a small survey of all the sockaddr_ variants: struct align size modulo where ------------------------------------------------------------------------- osockaddr 2 16 16 sockaddr 1 16 16 sockaddr_at 2 16 16 sockaddr_dl 2 54 2 sockaddr_hci 1 34 2 sockaddr_in 4 16 16 sockaddr_in6 4 28 4 sockaddr_inarp 4 16 16 sockaddr_ipx 2 16 16 sockaddr_l2cap 2 10 2 sockaddr_natm 2 22 2 sockaddr_nb 4 56 8 sockaddr_ng 1 16 16 sockaddr_rfcomm 1 9 1 sockaddr_sco 1 8 8 sockaddr_storage 8 128 128 sockaddr_un 1 106 2 If we push struct sockaddr to align(4), then we will also have to do the same with all others that are not already aligned to at least 4 bytes. That would be almost all of them. I agree that there will be ABI problems with those structs whose size is not a multiple of 4 (that's the ones with a value < 4 in the "modulo" column above). So we cannot do that, right? Best regards Oliver -- ``We are all but compressed light'' (Albert Einstein)