mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Horst von Brand <vonbrand@inf.utfsm.cl>
To: Anton Altaparmakov <aia21@cam.ac.uk>
Cc: Pekka J Enberg <penberg@cs.Helsinki.FI>,
	linux-ntfs-dev@lists.sourceforge.net,
	linux-kernel@vger.kernel.org, Linus Torvalds <torvalds@osdl.org>
Subject: Re: [PATCH 2/25] NTFS: Allow highmem kmalloc() in ntfs_malloc_nofs() and add _nofail() version.
Date: Fri, 09 Sep 2005 15:15:27 -0400	[thread overview]
Message-ID: <200509091915.j89JFREG011864@laptop11.inf.utfsm.cl> (raw)
In-Reply-To: Message from Anton Altaparmakov <aia21@cam.ac.uk>  of "Fri, 09 Sep 2005 13:08:58 +0100." <1126267738.32261.10.camel@imp.csi.cam.ac.uk>

Anton Altaparmakov <aia21@cam.ac.uk> wrote:
> On Fri, 2005-09-09 at 15:02 +0300, Pekka J Enberg wrote:
> > On Fri, 9 Sep 2005, Anton Altaparmakov wrote:

> > > > 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?).

> > Indeed. It is not just a matter of personal preference but also a matter 
> > of subsystems introducing duplicate code like this. Quick grepping shows 
> > UDF doing same thing  and XFS doing slightly differently but I am pretty 
> > sure I've seen it elsewhere too.

> Yes, that is usually a good indication that a generic function should be
> provided.  However having a generic function with complicated and long
> arguments is no use as everyone will want their own shorter one anyway.
> And given the function is static inline it actually makes no difference
> to the generated code size.  Also calling it __vmalloc_fast makes no
> sense as it doesn't always use vmalloc...  Given we have kmalloc and
> vmalloc maybe it should be just malloc?

That it makes no difference to the generated code isn't enough. If somebody
if going over the kernel with a fine comb trying to fix memory allocations
(example as here), she will have to remember half a dozen slightly
different ways of doing the same thing, for no good reason. And probably
miss a bundle in the process. This is bad in itself.

> Obviously if there were a suitable generic function I would use it but I
> and I imagine all the other users would still wrap it with the old name.

I'd hope not.

[Yes, I can understand that each subsystem has its own "culture", and
 trying to force them all into the same mold is friction too.]
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

  reply	other threads:[~2005-09-09 19:19 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-09  9:18 [2.6-GIT] NTFS: Release 2.1.24 Anton Altaparmakov
2005-09-09  9:19 ` [PATCH 1/25] NTFS: Support more clean journal ($LogFile) states Anton Altaparmakov
2005-09-09  9:19 ` [PATCH 2/25] NTFS: Allow highmem kmalloc() in ntfs_malloc_nofs() and add _nofail() version Anton Altaparmakov
2005-09-09 10:36   ` Pekka Enberg
2005-09-09 11:02     ` Anton Altaparmakov
2005-09-09 11:15       ` Pekka J Enberg
2005-09-09 11:25         ` Anton Altaparmakov
2005-09-09 11:38           ` Pekka J Enberg
2005-09-09 11:48             ` Anton Altaparmakov
2005-09-09 11:51               ` Anton Altaparmakov
2005-09-09 12:02                 ` Pekka J Enberg
2005-09-09 12:08                   ` Anton Altaparmakov
2005-09-09 19:15                     ` Horst von Brand [this message]
2005-09-09 14:51   ` Roland Dreier
2005-09-09 14:53     ` Christoph Hellwig
2005-09-09 14:58       ` Anton Altaparmakov
2005-09-09  9:21 ` [PATCH 3/25] NTFS: Use ntfs_malloc_nofs_nofail() in ntfs_runlists_merge() Anton Altaparmakov
2005-09-09  9:22 ` [PATCH 4/25] NTFS: Fix two nasty runlist merging bugs that had gone unnoticed so far Anton Altaparmakov
2005-09-09  9:22 ` [PATCH 5/25] NTFS: Remove two bogus BUG_ON()s from fs/ntfs/mft.c Anton Altaparmakov
2005-09-09  9:22 ` [PATCH 6/25] NTFS: Fix handling of valid but empty mapping pairs array Anton Altaparmakov
2005-09-09  9:23 ` [PATCH 7/25] NTFS: Report unrepresentable inodes during ntfs_readdir() as KERN_WARNING Anton Altaparmakov
2005-09-09  9:23 ` [PATCH 8/25] NTFS: Change ntfs_rl_truncate_nolock() to throw away the runlist if the new Anton Altaparmakov
2005-09-09  9:24 ` [PATCH 9/25] NTFS: Add ntfs_rl_punch_nolock() which punches a caller specified hole into a runlist Anton Altaparmakov
2005-09-09  9:24 ` [PATCH 10/25] NTFS: Fix a bug in fs/ntfs/index.c::ntfs_index_lookup() Anton Altaparmakov
2005-09-09  9:25 ` [PATCH 11/25] NTFS: Remove bogus setting of PageError in ntfs_read_compressed_block() Anton Altaparmakov
2005-09-09  9:26 ` [PATCH 12/25] NTFS: Add fs/ntfs/attrib.[hc]::ntfs_resident_attr_value_resize() Anton Altaparmakov
2005-09-09  9:26 ` [PATCH 13/25] NTFS: Fix several bugs in fs/ntfs/attrib.c Anton Altaparmakov
2005-09-09  9:27 ` [PATCH 14/25] NTFS: Fix handling of sparse attributes in ntfs_attr_make_non_resident() Anton Altaparmakov
2005-09-09  9:27 ` [PATCH 15/25] NTFS: Fix cluster (de)allocators to work when the runlist is NULL and more Anton Altaparmakov
2005-09-09  9:28 ` [PATCH 16/25] NTFS: Truncate {a,c,m}time to the ntfs supported time granularity when Anton Altaparmakov
2005-09-09  9:28 ` [PATCH 17/25] NTFS: Fixup handling of sparse, compressed, and encrypted attributes in Anton Altaparmakov
2005-09-09  9:28 ` [PATCH 18/25] NTFS: Make ntfs_write_block() not instantiate sparse blocks if they are zero Anton Altaparmakov
2005-09-09  9:29 ` [PATCH 19/25] NTFS: Fixup handling of sparse, compressed, and encrypted attributes in Anton Altaparmakov
2005-09-09  9:29 ` [PATCH 20/25] NTFS: Optimize fs/ntfs/aops.c::ntfs_write_block() by extending the page Anton Altaparmakov
2005-09-09  9:30 ` [PATCH 21/25] NTFS: Fix fs/ntfs/aops.c::ntfs_{read,write}_block() to handle the case Anton Altaparmakov
2005-09-09  9:30 ` [PATCH 22/25] NTFS: Fixup handling of sparse, compressed, and encrypted attributes in Anton Altaparmakov
2005-09-09  9:30 ` [PATCH 23/25] NTFS: Fix page_has_buffers()/page_buffers() handling in fs/ntfs/aops.c Anton Altaparmakov
2005-09-09  9:31 ` [PATCH 24/25] NTFS: Improve scalability by changing the driver global spin lock in Anton Altaparmakov
2005-09-09  9:32 ` [PATCH 25/25] NTFS: 2.1.24 release and some minor final fixes Anton Altaparmakov
2005-09-10 10:05 ` [2.6-GIT] NTFS: Release 2.1.24 Giuseppe Bilotta
2005-09-10 13:28   ` Anton Altaparmakov
2005-09-10 13:38     ` Anton Altaparmakov
2005-09-10 14:53     ` Bernd Eckenfels
2005-09-11 11:30     ` Giuseppe Bilotta
2005-09-12  2:13     ` Horst von Brand
2005-09-12  9:08       ` Anton Altaparmakov
2005-09-10 13:15 ` Alistair John Strachan
2005-09-10 13:23   ` Anton Altaparmakov
2005-09-25 19:12     ` Linux NTFS Vista compatibility (was: Re: [2.6-GIT] NTFS: Release 2.1.24.) Szakacsits Szabolcs
2005-09-25 22:35       ` Alistair John Strachan
2005-09-25 23:39         ` Szakacsits Szabolcs
2005-10-13 15:13         ` Alistair John Strachan
2005-10-13 15:18           ` Anton Altaparmakov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200509091915.j89JFREG011864@laptop11.inf.utfsm.cl \
    --to=vonbrand@inf.utfsm.cl \
    --cc=aia21@cam.ac.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-ntfs-dev@lists.sourceforge.net \
    --cc=penberg@cs.Helsinki.FI \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®