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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
