All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcin Slusarz <marcin.slusarz@gmail.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Ben Fennema <bfennema@falcon.csc.calpoly.edu>,
	Jan Kara <jack@suse.cz>
Subject: Re: [PATCH] udf: convert some macros to functions
Date: Mon, 7 Jan 2008 21:44:26 +0100	[thread overview]
Message-ID: <20080107204413.GB22144@joi> (raw)
In-Reply-To: <20080107122617.GB3710@infradead.org>

On Mon, Jan 07, 2008 at 12:26:18PM +0000, Christoph Hellwig wrote:
> On Sun, Jan 06, 2008 at 01:44:34AM +0100, marcin.slusarz@gmail.com wrote:
> > +static struct udf_bitmap *udf_sb_alloc_bitmap(struct super_block *sb, __u32 index)
> > +{
> > +	struct udf_part_map *map = &UDF_SB(sb)->s_partmaps[index];
> > +	int nr_groups = (map->s_partition_len + (sizeof(struct spaceBitmapDesc) << 3) +
> > +		(sb->s_blocksize * 8) - 1) / (sb->s_blocksize * 8);
> > +	int size = sizeof(struct udf_bitmap) + (sizeof(struct buffer_head *) * nr_groups);
> > +	struct udf_bitmap *bitmap;
> > +
> > +	if (size <= PAGE_SIZE)
> > +		bitmap = kmalloc(size, GFP_KERNEL);
> > +	else
> > +		bitmap = vmalloc(size);
> > +	if (bitmap != NULL) {
> > +		memset(bitmap, 0x00, size);
> > +		bitmap->s_block_bitmap = (struct buffer_head **)(bitmap + 1);
> > +		bitmap->s_nr_groups = nr_groups;
> > +	} else
> > +		udf_error(sb, __FUNCTION__, "Unable to allocate space for bitmap and %d buffer_head pointers", nr_groups);
> > +	return bitmap;
> > +}
> 
> There's some overly long lines here and some odd style, this should look
> more like:
These long lines were split later in "[PATCH 1/7] udf: fix coding style"
(but I will fix it in next version of this patch).

> static struct udf_bitmap *udf_sb_alloc_bitmap(struct super_block *sb,
> 		u32 index)
> {
> 	struct udf_part_map *map = &UDF_SB(sb)->s_partmaps[index];
> 	struct udf_bitmap *bitmap;
> 	int nr_groups;
> 	int size;
> 
> 	nr_groups = (map->s_partition_len +
> 		(sizeof(struct spaceBitmapDesc) << 3) +
> 		 (sb->s_blocksize * 8) - 1) /
> 		(sb->s_blocksize * 8);
> 	size = sizeof(struct udf_bitmap) +
> 		(sizeof(struct buffer_head *) * nr_groups);
> 	if (size <= PAGE_SIZE)
> 		bitmap = kmalloc(size, GFP_KERNEL);
> 	else
> 		bitmap = vmalloc(size);
> 
> 	if (!bitmap) {
> 		udf_error(sb, __FUNCTION__,
> 			  "Unable to allocate space for bitmap "
> 			  "and %d buffer_head pointers", nr_groups);
> 		return NULL;
> 	}
> 
> 	memset(bitmap, 0, size);
> 	bitmap->s_block_bitmap = (struct buffer_head **)(bitmap + 1);
> 	bitmap->s_nr_groups = nr_groups;
> 	return bitmap;
> }
Yep. This looks better.

> But even that is not quite optimal.  The nr_groups calculation should
> probably move to a helper (I suspect it's used elsewhere too anyway),
I will look for them. I've seen many weird calculations in udf code
and I think it's a good idea to move some of them into helpers.

> and instead of using vmalloc for large allocations I'd rather split
> the allocation of the bitmap from s->block_bitmap and use individual
> smaller allocations.  But that latter part is probably better left
> for a separate patch.
So every struct buffer_head * in bitmap will be indexed by a pair of:
idx >> ilog2(PAGE_SIZE / sizeof(struct buffer_head *))
idx & ((PAGE_SIZE / sizeof(struct buffer_head *)) - 1)
Am I right? Or did I misunderstand something?
I don't know how big nr_groups could be, but it might still need vmalloc
when array of pages won't fit on one page...

> But in generally this is a good cleanup and thanks a lot for working
> on this filesystem driver.
Thanks! :)

Marcin

  reply	other threads:[~2008-01-07 20:43 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-06  0:44 [PATCH 0/6] udf: improve code related to super_block v3 marcin.slusarz
2008-01-06  0:44 ` [PATCH] udf: fix coding style of super.c marcin.slusarz
2008-01-07 13:33   ` Jan Kara
2008-01-06  0:44 ` [PATCH] udf: remove some ugly macros marcin.slusarz
2008-01-06  0:44 ` [PATCH] udf: convert UDF_SB_ALLOC_PARTMAPS macro to udf_sb_alloc_partition_maps function marcin.slusarz
2008-01-06  0:44 ` [PATCH] udf: check if udf_load_logicalvol failed marcin.slusarz
2008-01-07 12:19   ` Christoph Hellwig
2008-01-06  0:44 ` [PATCH] udf: convert some macros to functions marcin.slusarz
2008-01-07 12:26   ` Christoph Hellwig
2008-01-07 20:44     ` Marcin Slusarz [this message]
2008-01-07 23:28       ` Andrew Morton
2008-01-08  6:52         ` Marcin Slusarz
2008-01-08 10:09       ` Jan Kara
2008-01-06  0:44 ` [PATCH] udf: fix sparse warnings (shadowing & mismatch between declaration and definition) marcin.slusarz
2008-01-07 12:26   ` Christoph Hellwig
2008-01-06  0:52 ` [PATCH 0/6] udf: improve code related to super_block v3 Marcin Slusarz

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=20080107204413.GB22144@joi \
    --to=marcin.slusarz@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=bfennema@falcon.csc.calpoly.edu \
    --cc=hch@infradead.org \
    --cc=jack@suse.cz \
    --cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.