linux-nvme.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Minwoo Im <minwoo.im.dev@gmail.com>
Cc: linux-nvme@lists.infradead.org, "Keith Busch" <kbusch@kernel.org>,
	"Jens Axboe" <axboe@fb.com>, "Christoph Hellwig" <hch@lst.de>,
	"Sagi Grimberg" <sagi@grimberg.me>,
	"Kanchan Joshi" <joshiiitr@gmail.com>,
	"Javier González" <javier.gonz@samsung.com>
Subject: Re: [PATCH V2 1/1] nvme: introduce generic per-namespace chardev
Date: Wed, 7 Apr 2021 15:15:27 +0200	[thread overview]
Message-ID: <20210407131527.GA15142@lst.de> (raw)
In-Reply-To: <20210406064841.103393-2-minwoo.im.dev@gmail.com>

On Tue, Apr 06, 2021 at 03:48:41PM +0900, Minwoo Im wrote:
> +static bool generic_ns = true;
> +module_param(generic_ns, bool, 0644);
> +MODULE_PARM_DESC(generic_ns, "support generic namespace character device");

I do not think the module option is a good idea.

> +#ifdef CONFIG_NVME_MULTIPATH
> +static int nvme_generic_ns_open(struct inode *inode, struct file *file)
> +{

The ifdef here means that the cases of either a subsystem that can't
have multiple controllers or the multipath=N option can't be handled
properly.  We really need two different code paths:  one with the
cdev in the namespace, and one with the cdev in the ns_head.  Just
like the gendisk.

> +	return nvme_ns_head_open(generic_ns->head->disk->part0, file->f_mode);

Calling this based on the bdev is a little silly when we can just
use the trivial underlying functionality.

> +	device_initialize(&generic_ns->device);
> +	generic_ns->device.devt = MKDEV(MAJOR(nvme_generic_ns_devt), minor);
> +	generic_ns->device.class = nvme_generic_ns_class;
> +	generic_ns->device.parent = ctrl->device;

We can't reference the controller for something hanging off the ns_head.

> +	/*
> +	 * If the namespace update fails in a graceful manner, hide the block
> +	 * device, but still allow for the generic namespae device to be
> +	 * craeted.
> +	 */
> +	if (nvme_update_ns_info(ns, id)) {
> +		if (generic_ns)
> +			ns->disk->flags |= GENHD_FL_HIDDEN;
> +		else
> +			goto out_put_disk;
> +	}

We must still fail when the error is one that does not just indicate
a not supported feature.

> +struct nvme_generic_ns {
> +	struct device		device;
> +	struct cdev		cdev;
> +	struct nvme_ns_head	*head;
> +
> +	/* targted namespace instance.  only valid in non-multipath */
> +	struct nvme_ns		*ns;
> +};

I don't really see point of this extra structure.



FYI, I've looked into addressing some of these points and will send
out an updated patch that sits on top of an ioctl and multipath
refatoring series I planned a while ago that I resurrected for this.

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

  reply	other threads:[~2021-04-07 13:16 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-06  6:48 [PATCH V2 0/1] nvme: introduce generic per-namespace chardev Minwoo Im
2021-04-06  6:48 ` [PATCH V2 1/1] " Minwoo Im
2021-04-07 13:15   ` Christoph Hellwig [this message]
2021-04-07 14:11     ` Minwoo Im
2021-04-07 14:21       ` Christoph Hellwig
2021-04-07 15:35         ` Minwoo Im
2021-04-07 15:40           ` Christoph Hellwig
2021-04-07 15:44             ` Minwoo Im
2021-04-07 15:47           ` Minwoo Im
2021-04-07 16:48             ` Christoph Hellwig
2021-04-07 16:59               ` Minwoo Im
2021-04-07 17:09               ` Minwoo Im
2021-04-07 17:14                 ` Christoph Hellwig
2021-04-08  7:11                   ` Javier González
2021-04-08  7:26                     ` Christoph Hellwig
2021-04-08 10:26                       ` Javier González
2021-04-08 11:27                         ` Christoph Hellwig
2021-04-08 11:46                           ` Javier González
2021-04-08 12:41                   ` Minwoo Im
2021-04-06  9:01 ` [PATCH V2 0/1] " Niklas Cassel
2021-04-06 13:35   ` Minwoo Im
2021-04-06 14:59     ` Christoph Hellwig
2021-04-06 16:23       ` Minwoo Im
2021-04-07  6:00         ` Christoph Hellwig
2021-04-07  6:02           ` Minwoo Im
2021-04-07  7:36       ` Niklas Cassel
2021-04-07  9:39         ` Christoph Hellwig
2021-04-07 10:00           ` Niklas Cassel
2021-04-07 10:34           ` Damien Le Moal
2021-04-07 11:50             ` Javier González
2021-04-06 14:13   ` Kanchan Joshi

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=20210407131527.GA15142@lst.de \
    --to=hch@lst.de \
    --cc=axboe@fb.com \
    --cc=javier.gonz@samsung.com \
    --cc=joshiiitr@gmail.com \
    --cc=kbusch@kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=minwoo.im.dev@gmail.com \
    --cc=sagi@grimberg.me \
    /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;
as well as URLs for NNTP newsgroup(s).