Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751350AbVIILv5 (ORCPT ); Fri, 9 Sep 2005 07:51:57 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751368AbVIILv5 (ORCPT ); Fri, 9 Sep 2005 07:51:57 -0400 Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130]:41668 "EHLO ppsw-0.csi.cam.ac.uk") by vger.kernel.org with ESMTP id S1751350AbVIILv5 (ORCPT ); Fri, 9 Sep 2005 07:51:57 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Subject: Re: [PATCH 2/25] NTFS: Allow highmem kmalloc() in ntfs_malloc_nofs() and add _nofail() version. From: Anton Altaparmakov To: Pekka J Enberg Cc: linux-ntfs-dev@lists.sourceforge.net, linux-kernel@vger.kernel.org, Linus Torvalds In-Reply-To: <1126266508.32261.3.camel@imp.csi.cam.ac.uk> References:

<84144f0205090903366454da6@mail.gmail.com> <1126263740.24291.16.camel@imp.csi.cam.ac.uk> <1126265138.24291.21.camel@imp.csi.cam.ac.uk> <1126266508.32261.3.camel@imp.csi.cam.ac.uk> Content-Type: text/plain Organization: Computing Service, University of Cambridge, UK Date: Fri, 09 Sep 2005 12:51:41 +0100 Message-Id: <1126266702.32261.5.camel@imp.csi.cam.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2338 Lines: 50 On Fri, 2005-09-09 at 12:48 +0100, Anton Altaparmakov wrote: > On Fri, 2005-09-09 at 14:38 +0300, Pekka J Enberg wrote: > > On Fri, 9 Sep 2005, Anton Altaparmakov wrote: > > > They could be but I would rather not. What if one day I decide to > > > change how ntfs_malloc_nofs() works? Then it would be needed to > > > carefully go through the whole driver looking for places where kmalloc > > > is used and change those, too. > > > > > > From a software design point of view you should never mix interfaces > > > when accessing an object if you want clean and maintainable code. And > > > using kmalloc() sometimes and ntfs_malloc_nofs() at other times for the > > > same object would violate that. > > > > > > The wrapper is a static inline so I would assume gcc can optimize away > > > everything when a constant size is passed in like in the example you > > > point out above. > > > > Hey, I am not worried about performance. It's just that filesystems (or > > any other subsystem for that matter) should not invent their own memory > > allocators. Perhaps should provide a generic __vmalloc_fast() if this is > > really required? > > Even if that were the case I would still use a wrapper. I am far too > lazy to write __vmalloc(x, GFP_NOFS | __GFP_HIGHMEM); or even > __vmalloc(x, GFP_NOFS | __GFP_HIGHMEM | __GFP_NOFAIL); when I can get > away with ntfs_malloc_nofs{,nofail}()... (-; > > I completely disagree with you given that this is not "inventing [...] > own memory allocators", it is just a convenient short hand. I am sure a > lot of people would agree with you though. It is just a matter of > personal preference. I should add that this is not ntfs only, the idea is from another file system which uses it, too. Can't remember which one it was, though (xfs maybe?). 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/