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 <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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
|
|