public inbox for linux-bcache@vger.kernel.org
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: Coly Li <colyli@suse.de>, linux-bcache@vger.kernel.org
Cc: linux-block@vger.kernel.org
Subject: Re: [PATCH 14/14] bcache: move struct cache_sb out of uapi bcache.h
Date: Mon, 17 Aug 2020 08:36:50 +0200	[thread overview]
Message-ID: <809bef2f-af92-1071-685d-6454fa93b50c@suse.de> (raw)
In-Reply-To: <20200815041043.45116-15-colyli@suse.de>

On 8/15/20 6:10 AM, Coly Li wrote:
> struct cache_sb does not exactly map to cache_sb_disk, it is only for
> in-memory super block and dosn't belong to uapi bcache.h.
> 
> This patch moves the struct cache_sb definition and other depending
> macros and inline routines from include/uapi/linux/bcache.h to
> drivers/md/bcache/bcache.h, this is the proper location to have them.
> 
And that I'm not sure of.
The 'uapi' directory is there to hold the user-visible kernel API.
So the real question is whether the bcache superblock is or should be 
part of the user API or not.
Hence an alternative way would be to detail out the entire superblock in
include/uapi/linux/bcache.h, and remove the definitions from
drivers/md/bcache/bcache.h.

There doesn't seem to be a consistent policy here; some things like MD 
have their superblock in the uapi directory, others like btrfs only have 
the ioctl definitions there.

I'm somewhat in favour of having the superblock definition as part of 
the uapi, as this would make writing external tools like blkid easier.
But then the ultimate decision is yours.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke            Teamlead Storage & Networking
hare@suse.de                               +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer

  reply	other threads:[~2020-08-17  6:36 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-15  4:10 [PATCH 00/14] bcache: remove multiple caches code framework Coly Li
2020-08-15  4:10 ` [PATCH 01/14] bcache: remove 'int n' from parameter list of bch_bucket_alloc_set() Coly Li
2020-08-17  6:08   ` Hannes Reinecke
2020-08-15  4:10 ` [PATCH 02/14] bcache: explicitly make cache_set only have single cache Coly Li
2020-08-17  6:11   ` Hannes Reinecke
2020-08-15  4:10 ` [PATCH 03/14] bcache: remove for_each_cache() Coly Li
2020-08-17  6:13   ` Hannes Reinecke
2020-08-22 11:40     ` Coly Li
2020-08-15  4:10 ` [PATCH 04/14] bcache: add set_uuid in struct cache_set Coly Li
2020-08-17  6:15   ` Hannes Reinecke
2020-08-15  4:10 ` [PATCH 05/14] bcache: only use block_bytes() on struct cache Coly Li
2020-08-17  6:16   ` Hannes Reinecke
2020-08-15  4:10 ` [PATCH 06/14] bcache: remove useless alloc_bucket_pages() Coly Li
2020-08-17  6:17   ` Hannes Reinecke
2020-08-15  4:10 ` [PATCH 07/14] bcache: remove useless bucket_pages() Coly Li
2020-08-17  6:18   ` Hannes Reinecke
2020-08-15  4:10 ` [PATCH 08/14] bcache: only use bucket_bytes() on struct cache Coly Li
2020-08-17  6:19   ` Hannes Reinecke
2020-08-15  4:10 ` [PATCH 09/14] bcache: avoid data copy between cache_set->sb and cache->sb Coly Li
2020-08-17  6:22   ` Hannes Reinecke
2020-08-17  6:30     ` Coly Li
2020-08-15  4:10 ` [PATCH 10/14] bcache: don't check seq numbers in register_cache_set() Coly Li
2020-08-17  6:23   ` Hannes Reinecke
2020-08-15  4:10 ` [PATCH 11/14] bcache: remove can_attach_cache() Coly Li
2020-08-17  6:24   ` Hannes Reinecke
2020-08-15  4:10 ` [PATCH 12/14] bcache: check and set sync status on cache's in-memory super block Coly Li
2020-08-17  6:25   ` Hannes Reinecke
2020-08-15  4:10 ` [PATCH 13/14] bcache: remove embedded struct cache_sb from struct cache_set Coly Li
2020-08-17  6:26   ` Hannes Reinecke
2020-08-15  4:10 ` [PATCH 14/14] bcache: move struct cache_sb out of uapi bcache.h Coly Li
2020-08-17  6:36   ` Hannes Reinecke [this message]
2020-08-17  7:10     ` Coly Li
2020-08-17 10:28   ` Christoph Hellwig
2020-08-17 11:48     ` Coly Li

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=809bef2f-af92-1071-685d-6454fa93b50c@suse.de \
    --to=hare@suse.de \
    --cc=colyli@suse.de \
    --cc=linux-bcache@vger.kernel.org \
    --cc=linux-block@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox