From: Christoph Hellwig <hch@lst.de>
To: Daniel Wagner <dwagner@suse.de>
Cc: linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org,
Keith Busch <kbusch@kernel.org>, Christoph Hellwig <hch@lst.de>,
Sagi Grimberg <sagi@grimberg.me>, Hannes Reinecke <hare@suse.de>
Subject: Re: [RFC v1] nvme: add cse, ds, ms, nsze and nuse to sysfs
Date: Mon, 27 Nov 2023 15:18:57 +0100 [thread overview]
Message-ID: <20231127141857.GA25833@lst.de> (raw)
In-Reply-To: <20231127103208.25748-1-dwagner@suse.de>
On Mon, Nov 27, 2023 at 11:32:08AM +0100, Daniel Wagner wrote:
> Also getting a pointer to the nvme_ns data structure is a bit strange
> (dev_to_nvme_ns).
> This stip is necessary as many of the ns attributes are in
> nvme_ns. Shouldn't these per path values not all be the same and thus couldn't
> these be in nvme_ns_head? Anyway, just not sure who to deal with this. So any
> pointers highly welcomed!
Yes, they probably should be in the ns_head.
> + list_for_each_entry(ctrl, &subsys->ctrls, subsys_entry) {
> + down_read(&ctrl->namespaces_rwsem);
> + list_for_each_entry(ns, &ctrl->namespaces, list) {
> + ret = ns;
> + break;
> + }
> + up_read(&ctrl->namespaces_rwsem);
> + }
> + return ret;
> + }
.. I also don't think this would even be safe as-is as we dont hold
a reference to the ns after dropping the lock.
> +static ssize_t csi_show(struct device *dev, struct device_attribute *attr,
> + char *buf)
> +{
> + return sysfs_emit(buf, "%d\n", dev_to_ns_head(dev)->ids.csi);
> +}
> +static DEVICE_ATTR_RO(csi);
> +
> +static ssize_t lba_ds_show(struct device *dev, struct device_attribute *attr,
> + char *buf)
> +{
> + struct nvme_ns *ns = dev_to_nvme_ns(dev);
> +
> + return sysfs_emit(buf, "%d\n", ns->lba_shift);
lba_ds is a bit of an odd name. And I also don't think we even need
this, because it really is just a weird enconding for the logical block
size already exposed by the block layer.
> +static ssize_t lba_ms_show(struct device *dev, struct device_attribute *attr,
> + char *buf)
> +{
> + struct nvme_ns *ns = dev_to_nvme_ns(dev);
> +
> + return sysfs_emit(buf, "%d\n", ns->ms);
> +}
> +static DEVICE_ATTR_RO(lba_ms);
I'd probably spell out metadata_size, or probably even better
metadata_bytes to match the unit postfixes elsewhere in the block code.
> +
> +static ssize_t nsze_show(struct device *dev, struct device_attribute *attr,
> + char *buf)
> +{
> + struct nvme_ns *ns = dev_to_nvme_ns(dev);
> +
> + return sysfs_emit(buf, "%llu\n", ns->nsze);
> +}
> +static DEVICE_ATTR_RO(nsze);
This is just the normal size of the block device we already export.
next prev parent reply other threads:[~2023-11-27 14:19 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-27 10:32 [RFC v1] nvme: add cse, ds, ms, nsze and nuse to sysfs Daniel Wagner
2023-11-27 10:44 ` Keith Busch
2023-11-27 12:07 ` Daniel Wagner
2023-11-27 13:57 ` Christoph Hellwig
2023-11-27 14:18 ` Christoph Hellwig [this message]
2023-11-27 15:44 ` Keith Busch
2023-11-27 15:56 ` Christoph Hellwig
2023-11-27 16:30 ` Keith Busch
2023-11-27 16:33 ` Christoph Hellwig
2023-11-27 16:46 ` Keith Busch
2023-11-28 8:21 ` Daniel Wagner
2023-11-28 10:06 ` Sagi Grimberg
2023-11-28 13:05 ` Christoph Hellwig
2023-11-28 19:02 ` Keith Busch
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=20231127141857.GA25833@lst.de \
--to=hch@lst.de \
--cc=dwagner@suse.de \
--cc=hare@suse.de \
--cc=kbusch@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--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 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.