From owner-cvs-src@FreeBSD.ORG Fri Nov 17 17:32:43 2006 Return-Path: X-Original-To: cvs-src@FreeBSD.ORG Delivered-To: cvs-src@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D0B0F16A403; Fri, 17 Nov 2006 17:32:43 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E47043D46; Fri, 17 Nov 2006 17:32:43 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id kAHHUIMT080755; Fri, 17 Nov 2006 10:30:20 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 17 Nov 2006 10:30:58 -0700 (MST) Message-Id: <20061117.103058.-165354141.imp@bsdimp.com> To: yar@comp.chem.msu.su From: "M. Warner Losh" In-Reply-To: <20061117065555.GE49602@comp.chem.msu.su> References: <20061116090412.GB37133@comp.chem.msu.su> <20061116.165207.1661914048.imp@bsdimp.com> <20061117065555.GE49602@comp.chem.msu.su> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Fri, 17 Nov 2006 10:30:22 -0700 (MST) Cc: src-committers@FreeBSD.ORG, bde@zeta.org.au, jkoshy@FreeBSD.ORG, cvs-all@FreeBSD.ORG, phk@phk.freebsd.dk, cvs-src@FreeBSD.ORG Subject: Re: cvs commit: src/include ar.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 17:32:43 -0000 In message: <20061117065555.GE49602@comp.chem.msu.su> Yar Tikhiy writes: : On Thu, Nov 16, 2006 at 04:52:07PM -0700, M. Warner Losh wrote: : > In message: <20061116090412.GB37133@comp.chem.msu.su> : > Yar Tikhiy writes: : > : On Mon, Nov 13, 2006 at 10:19:58AM -0700, M. Warner Losh wrote: : > : > : : > : > : BTW, you are responsible for the __packed in . Please remove : > : > : it. The __CTASSERT() is enough to detect if heroic packing is ever needed. : > : > : The only danger is if something has grown to depend on __packed reducing : > : > : alignment as a side effect. E.g., suppose we had a byte string containing : > : > : a bytewise copy of a struct ip. If the copy might be misaligned, then it : > : > : should be copied to an actual struct ip before accessing it as a struct, : > : > : but code that accesses it directly using ((struct ip *)&bs[N]) would work : > : > : now due to the reduced alignment. Places that really need __packed should : > : > : probably use __aligned() to restore the natural alignment. : > : > : > : > DO NOT REMOVE IT. IT IS ABSOLUTELY REQUIRED FOR ARM TO WORK RIGHT. : > : > If you want to remove it, then you must make sure arm works right : > : > after it because I'll add it back. : > : : > : Many years ago I was taught that comments in code could help to : > : avoid such clashes in software development. Is this true no more? ;-) : > > : > You don't add comments like: : > : > i++; // Add one to i. : > : > This is a similar class. It is for any compiler that has differing : > alignment requirements than i386. : : This is an oversimplification of the case. If it were so simple, : no doubts about it would be raised. That's why I suggested adding : a comment explaining that historically struct ip was lucky to be : packed/aligned properly, but that wasn't backed by the C standard : in fact, and eventually architectures appeared, e.g., ARM, which : broke the false assumption. It's a rather edifying case. Then : you'll have a smaller chance of having to yell in capital letters : again, "DO NOT REMOVE IT. IT IS ABSOLUTELY REQUIRED FOR ARM TO : WORK RIGHT." -- hopefully, not only regarding struct ip. The point I'm trying to make is that there are likely to be many of these instances in the tree. And there may be architectures other than ARM that have this alignment issue. You can't put a larage number of them into the tree without it looking odd or quaint. A few years from now, comments like this will look odd too. NetBSD, for example, has these all over the place. Warner