linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Dan Streetman <ddstreet@ieee.org>
To: Souptick Joarder <jrdr.linux@gmail.com>
Cc: Seth Jennings <sjenning@redhat.com>, Linux-MM <linux-mm@kvack.org>
Subject: Re: [PATCH] mm: zbud: Remove zbud_map() and zbud_unmap() function
Date: Mon, 19 Feb 2018 09:15:59 -0500	[thread overview]
Message-ID: <CALZtONBW8imhSCu5RU68U0L+TtYiOgAdzwZa0NdrgVEGdSGELw@mail.gmail.com> (raw)
In-Reply-To: <20180217161230.GA16890@jordon-HP-15-Notebook-PC>

On Sat, Feb 17, 2018 at 11:12 AM, Souptick Joarder <jrdr.linux@gmail.com> wrote:
> zbud_unmap() is empty function and not getting called from
> anywhere except from zbud_zpool_unmap(). Hence we can remove
> zbud_unmap().
>
> Similarly, zbud_map() is only returning (void *)(handle)
> which can be done within zbud_zpool_map(). Hence we can
> remove zbud_map().

The comments at the top of zbud.c talk about using zbud_map() and
zbud_unmap(), so just removing the functions without changing the doc
in the file is not right.

Additionally, the functions will get compiled out, so this change
won't actually make any difference in the compiled kernel.

Finally, removing them from the header file makes the zbud API
effectively unusable for any code except zpool, so it would be
pointless to leave zbud.h in include/linux (which it doesn't
necessarily need to be in anyway, but that's a different topic).

I'd prefer to just leave zbud_map/zbud_unmap in the API, so NAK from me.

>
> Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
> ---
>  include/linux/zbud.h |  2 --
>  mm/zbud.c            | 30 ++----------------------------
>  2 files changed, 2 insertions(+), 30 deletions(-)
>
> diff --git a/include/linux/zbud.h b/include/linux/zbud.h
> index b1eaf6e..565b88c 100644
> --- a/include/linux/zbud.h
> +++ b/include/linux/zbud.h
> @@ -16,8 +16,6 @@ int zbud_alloc(struct zbud_pool *pool, size_t size, gfp_t gfp,
>         unsigned long *handle);
>  void zbud_free(struct zbud_pool *pool, unsigned long handle);
>  int zbud_reclaim_page(struct zbud_pool *pool, unsigned int retries);
> -void *zbud_map(struct zbud_pool *pool, unsigned long handle);
> -void zbud_unmap(struct zbud_pool *pool, unsigned long handle);
>  u64 zbud_get_pool_size(struct zbud_pool *pool);
>
>  #endif /* _ZBUD_H_ */
> diff --git a/mm/zbud.c b/mm/zbud.c
> index 28458f7..c83c876 100644
> --- a/mm/zbud.c
> +++ b/mm/zbud.c
> @@ -188,11 +188,11 @@ static int zbud_zpool_shrink(void *pool, unsigned int pages,
>  static void *zbud_zpool_map(void *pool, unsigned long handle,
>                         enum zpool_mapmode mm)
>  {
> -       return zbud_map(pool, handle);
> +       return (void *)(handle);
>  }
>  static void zbud_zpool_unmap(void *pool, unsigned long handle)
>  {
> -       zbud_unmap(pool, handle);
> +
>  }
>
>  static u64 zbud_zpool_total_size(void *pool)
> @@ -569,32 +569,6 @@ int zbud_reclaim_page(struct zbud_pool *pool, unsigned int retries)
>  }
>
>  /**
> - * zbud_map() - maps the allocation associated with the given handle
> - * @pool:      pool in which the allocation resides
> - * @handle:    handle associated with the allocation to be mapped
> - *
> - * While trivial for zbud, the mapping functions for others allocators
> - * implementing this allocation API could have more complex information encoded
> - * in the handle and could create temporary mappings to make the data
> - * accessible to the user.
> - *
> - * Returns: a pointer to the mapped allocation
> - */
> -void *zbud_map(struct zbud_pool *pool, unsigned long handle)
> -{
> -       return (void *)(handle);
> -}
> -
> -/**
> - * zbud_unmap() - maps the allocation associated with the given handle
> - * @pool:      pool in which the allocation resides
> - * @handle:    handle associated with the allocation to be unmapped
> - */
> -void zbud_unmap(struct zbud_pool *pool, unsigned long handle)
> -{
> -}
> -
> -/**
>   * zbud_get_pool_size() - gets the zbud pool size in pages
>   * @pool:      pool whose size is being queried
>   *
> --
> 1.9.1
>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2018-02-19 14:16 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-17 16:12 Souptick Joarder
2018-02-19 14:15 ` Dan Streetman [this message]
2018-02-19 17:48   ` Souptick Joarder

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=CALZtONBW8imhSCu5RU68U0L+TtYiOgAdzwZa0NdrgVEGdSGELw@mail.gmail.com \
    --to=ddstreet@ieee.org \
    --cc=jrdr.linux@gmail.com \
    --cc=linux-mm@kvack.org \
    --cc=sjenning@redhat.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