Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S269438AbUIYXJw (ORCPT ); Sat, 25 Sep 2004 19:09:52 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S269439AbUIYXJw (ORCPT ); Sat, 25 Sep 2004 19:09:52 -0400 Received: from ppsw-3.csi.cam.ac.uk ([131.111.8.133]:25058 "EHLO ppsw-3.csi.cam.ac.uk") by vger.kernel.org with ESMTP id S269438AbUIYXJu (ORCPT ); Sat, 25 Sep 2004 19:09:50 -0400 Date: Sun, 26 Sep 2004 00:09:47 +0100 (BST) From: Anton Altaparmakov To: viro@parcelfarce.linux.theplanet.co.uk cc: Linus Torvalds , Andrew Morton , linux-kernel@vger.kernel.org, linux-ntfs-dev@lists.sourceforge.net Subject: Re: [PATCH 6/10] Re: [2.6-BK-URL] NTFS: 2.1.19 sparse annotation, cleanups and a bugfix In-Reply-To: <20040925063519.GQ23987@parcelfarce.linux.theplanet.co.uk> Message-ID: References:

<20040925063519.GQ23987@parcelfarce.linux.theplanet.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2390 Lines: 48 On Sat, 25 Sep 2004 viro@parcelfarce.linux.theplanet.co.uk wrote: > On Fri, Sep 24, 2004 at 05:13:53PM +0100, Anton Altaparmakov wrote: > > /* Get the starting vcn of the index_block holding the child node. */ > > - vcn = sle64_to_cpup((u8*)ie + le16_to_cpu(ie->length) - 8); > > + vcn = sle64_to_cpup((sle64*)((u8*)ie + le16_to_cpu(ie->length) - 8)); > > I don't like the look of that. Are there any alignment warranties for that > pointer? The same goes for other users of that function... The above pointer is always aligned to 8-byte boundary as goes for all users of sle64_to_cpup(). If that matters, everything using _to_cpup() in ntfs is aligned sufficiently expect for perhaps the two uses of le32_to_cpu() in fs/ntfs/collate.c and the four uses of le16_to_cpu() in fs/ntfs/compress.c where I would not be so sure and in fact the compress.c ones I am pretty sure that there is no alignement guarantee for anything at all. Simillar, some of the othe *le*_to_cpu() conversion in NTFS are not aligned (especially most of the boot sector ones). I decided to not use the get_unaligned macros despite of this after a discussion on LKML (perhaps fs-devel or perhaps only #kernel several years ago, can't remember) where it was discussed that all architectures can do the appropriate fixups on unaligned accesses if they need them and that get_unaligned makes code very slow so it is better to just do the accesses and have high speed on architectures which don't care and to have fixups on other architectures than it is to use get_unaligned everywhere. Is there anything wrong with that? Remember that NTFS in real life is almost entirely restricted to x86 which AFAIK doesn't care about alignement. I guess Windows now also exists (as beta) for ia64 and x86_64 but I don't know if these architectures require alignment or not... Best regards, Anton -- Anton Altaparmakov (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/