All of lore.kernel.org
 help / color / mirror / Atom feed
From: Niklas Cassel <Niklas.Cassel@wdc.com>
To: Andreas Hindborg <nmi@metaspace.dk>
Cc: "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"Hans Holmberg" <Hans.Holmberg@wdc.com>,
	"Matias Bjørling" <Matias.Bjorling@wdc.com>,
	"kernel test robot" <lkp@intel.com>,
	"Ming Lei" <ming.lei@redhat.com>, "Jens Axboe" <axboe@kernel.dk>,
	"open list" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] block: ublk: enable zoned storage support
Date: Mon, 27 Feb 2023 14:29:37 +0000	[thread overview]
Message-ID: <Y/y+UFEHn1F1sg4i@x1-carbon> (raw)
In-Reply-To: <87ttz79u8p.fsf@metaspace.dk>

On Mon, Feb 27, 2023 at 12:59:45PM +0100, Andreas Hindborg wrote:

(snip)

> >> +#else
> >> +void ublk_set_nr_zones(struct ublk_device *ub);
> >> +void ublk_dev_param_zoned_apply(struct ublk_device *ub);
> >> +int ublk_revalidate_disk_zones(struct gendisk *disk);
> >
> > These are declarations, shouldn't they be dummy definitions instead?
> 
> I looked at how nvme host defines nvme_revalidate_zones() when I did
> this. The functions become undefined symbols but because the call sites
> are optimized out they go away.

Looking at e.g. nvme_revalidate_zones

$ git grep nvme_revalidate_zones
drivers/nvme/host/core.c:               ret = nvme_revalidate_zones(ns);
drivers/nvme/host/nvme.h:int nvme_revalidate_zones(struct nvme_ns *ns);
drivers/nvme/host/zns.c:int nvme_revalidate_zones(struct nvme_ns *ns)

The function is declared in nvme.h, but like you say, without any definition.

zns.c provides a definition, but that file is only build if
CONFIG_BLK_DEV_ZONED is set.


> > https://github.com/torvalds/linux/blob/v6.2/fs/btrfs/Makefile#L39
> > https://github.com/torvalds/linux/blob/v6.2/drivers/block/null_blk/Makefile#L11
> >
> > They have put the zoned stuff in a separate C file that is only compiled
> > when CONFIG_BLK_DEV_ZONED is set.
> >
> > I'm not sure if a similar design is desired for ublk or not.
> >
> > However, if a similar design pattern was used, it could probably avoid
> > some of these unpleasant dummy definitions altogether.
> 
> This is the same as I do here, except I put the declarations in the c
> file instead of a header. I did this for two reasons 1) there is no ublk
> header besides the uapi header (I would add a header just for this), 2)
> the declarations need only exist inside ublk_drv.c. For btrfs, null_blk,
> nvme, the declarations go in a header file and the functions in question
> do not have static linkage.
> 
> I could move the function declarations out of the #else block, but then
> they would need to be declared static and that gives a compiler warning
> when the implementation is not present.

I would love to hear someone else's opinion about this as well, but I do
think that having #ifdef and #else with both a declaration and a definition
in the C file is quite ugly.

If having an internal only header (in the same directory as the C file),
makes the C code easier to read, I'm all for it.

It seems to work for nvme to only have a declaration in an internal header
file, and only provide a definition if CONFIG_BLK_DEV_ZONED is set,
presumably without giving a warning. Perhaps ublk can do the same?


Kind regards,
Niklas

  reply	other threads:[~2023-02-27 14:29 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-24 20:05 [PATCH v2] block: ublk: enable zoned storage support Andreas Hindborg
2023-02-27 10:20 ` Niklas Cassel
2023-02-27 11:59   ` Andreas Hindborg
2023-02-27 14:29     ` Niklas Cassel [this message]
2023-02-27 14:41       ` Andreas Hindborg
2023-02-27 15:20 ` Minwoo Im
2023-02-27 15:36   ` Andreas Hindborg
2023-02-28  9:52 ` Hans Holmberg
2023-03-01  7:28   ` Andreas Hindborg
2023-03-02  2:50 ` Ming Lei
2023-03-02  7:31   ` Andreas Hindborg
2023-03-02  8:19     ` Damien Le Moal
2023-03-02  8:32     ` Ming Lei
2023-03-02  9:01       ` Ming Lei
2023-03-02  9:14         ` Ming Lei
2023-03-02 10:07           ` Andreas Hindborg
2023-03-02 13:16             ` Ming Lei
2023-03-02 13:28               ` Andreas Hindborg
2023-03-03  2:59                 ` Ming Lei
2023-03-03  8:27                   ` Andreas Hindborg
2023-03-03 11:47                     ` Ming Lei

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=Y/y+UFEHn1F1sg4i@x1-carbon \
    --to=niklas.cassel@wdc.com \
    --cc=Hans.Holmberg@wdc.com \
    --cc=Matias.Bjorling@wdc.com \
    --cc=axboe@kernel.dk \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=ming.lei@redhat.com \
    --cc=nmi@metaspace.dk \
    /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.