mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Mark Peloquin" <peloquin@us.ibm.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: torvalds@transmeta.com, linux-kernel@vger.kernel.org,
	evms-devel@lists.sourceforge.net
Subject: Re: [Evms-devel] Re: [PATCH] EVMS core 4/4: evms_biosplit.h
Date: Thu, 3 Oct 2002 15:36:24 -0500	[thread overview]
Message-ID: <OF2FC09D0D.E4C956E8-ON85256C47.006ECCC8@pok.ibm.com> (raw)


On 10/03/2002 at 10:05 AM, Christoph Hellwig wrote:

>> +static mempool_t *my_bio_split_pool, *my_bio_pool;
>> +static kmem_cache_t *my_bio_split_slab, *my_bio_pool_slab;

> Umm, static variables in header files?

Yupp, that wasn't accidental.

Based on the conclusions mutually agreed on in the OLS
BOF on bio splitting, it was decided that each driver
having the need to split bios *should* have their own
private bio pools to use exclusively for this purpose.
Thus any plugin that includes this header gets their
own private copies of these variables.

>> +
>> +/**
>> + * slab_pool_alloc
>> + * @gfp_mask: GFP allocation flag
>> + * @data:     mempool prototype required fields
>> + *
>> + * mempool allocate function
>> + **/
>> +static void *
>> +slab_pool_alloc(int gfp_mask, void *data)
>> +{
>> +  return kmem_cache_alloc(data, gfp_mask);
>> +}
>> +
>> +/**
>> + * slab_pool_free
>> + * @ptr:      mempool prototype required fields
>> + * @data:     mempool prototype required fields
>> + *
>> + * mempool free function
>> + **/
>> +static void
>> +slab_pool_free(void *ptr, void *data)
>> +{
>> +  kmem_cache_free(data, ptr);
>> +}

> I think these two could go to slab.c instead.

I agree. I've seen a few other static versions of the
same thing floating around.

>> +  if (!my_bio_split_slab) {
>> +        panic("unable to create EVMS Bio Split cache.");

> What about graceful error handling?

Alan already questioned this as well... and I agree. I've
already made the necessary changes.

> All in all I think this should rather be a source file, I can't
> see anything EVMS-specific either.

There may likely be generic code to perform bio splitting
at some (hopefully soon) point in time. I'm not even going
to assume that what EVMS has done will or should be it.
This support was a temporary implementation that does
allow several plugins in EVMS to work correctly with the
large I/Os now available in 2.5. I do agree, what ever is
done should be placed in some commonly usable location.

Mark



             reply	other threads:[~2002-10-03 20:26 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-03 20:36 Mark Peloquin [this message]
2002-10-04 14:16 ` Christoph Hellwig
  -- strict thread matches above, loose matches on Subject: below --
2002-10-03 14:10 Mark Peloquin

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=OF2FC09D0D.E4C956E8-ON85256C47.006ECCC8@pok.ibm.com \
    --to=peloquin@us.ibm.com \
    --cc=evms-devel@lists.sourceforge.net \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.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 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®