Re: [PATCH 2/25] NTFS: Allow highmemkmalloc() in ntfs_malloc_nofs() and add _nofail() version.

[Anton Altaparmakov]

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.

Best regards,

        Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/