All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kent Overstreet <kent.overstreet@gmail.com>
To: Randy Dunlap <randy.dunlap@oracle.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH] bcache: ver 3
Date: Fri, 23 Apr 2010 13:05:02 -0800	[thread overview]
Message-ID: <4BD20B7E.2070201@gmail.com> (raw)
In-Reply-To: <20100423133910.d36e2b22.randy.dunlap@oracle.com>

On 04/23/2010 12:39 PM, Randy Dunlap wrote:

>> +#define label(l, foo)	if (0) { l: foo; }
>
> I'd prefer that macro to go away.

I kind of like it, the way I use it it's shorthand for "return with x status"; 
it just makes return codes and exiting cleaner. But if you still hate it after 
you've read the functions where it's used, I can take it out.

>> +	return d[i / keys_per_page] + (i % keys_per_page);
>
> That builds OK on i386?  or does it need udivdi3() and/or umoddi3()?

If my understanding is correct, those are only needed for 64 bits, i indexes 
into a single node so 32 bits is plenty.

>
>> +}
>
>> +static int lookup_dev(struct cache_device *c, struct bio *bio)
>> +{
>> +	int dev;
>> +	for (dev = 0; dev<  256; dev++)
>
> Use a macro for 256.. in lots of places.

Yes, definitely.

> 		bcache: cannot allocate memory
> "kmalloc error" sounds like kmalloc() had an internal error.

Agreed.

> Need to document the sysfs interfaces:

Ok, I'll start on that.

>> +	err = "vmalloc error";
>
> 		"cannot vmalloc memory";

Done.

  reply	other threads:[~2010-04-23 21:05 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-23 19:41 [RFC][PATCH] bcache: ver 3 Kent Overstreet
2010-04-23 20:07 ` Randy Dunlap
2010-04-23 20:17   ` Kent Overstreet
2010-04-23 20:19     ` Randy Dunlap
2010-04-23 20:46       ` Kent Overstreet
2010-04-23 20:39 ` Randy Dunlap
2010-04-23 21:05   ` Kent Overstreet [this message]
2010-04-25 11:48 ` Pavel Machek
  -- strict thread matches above, loose matches on Subject: below --
2010-04-24 15:47 Egon Alter
2010-04-24 20:08 ` Kent Overstreet

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=4BD20B7E.2070201@gmail.com \
    --to=kent.overstreet@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=randy.dunlap@oracle.com \
    /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.