From: Karel Zak <kzak@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Hannes Reinecke <hare@suse.de>, Sagi Grimberg <sagi@grimberg.me>,
Keith Busch <kbusch@kernel.org>,
linux-nvme@lists.infradead.org, util-linux@vger.kernel.org,
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Subject: Re: [PATCH] nvme: add namespace paths links
Date: Mon, 25 Apr 2022 15:54:09 +0200 [thread overview]
Message-ID: <20220425135409.zov6h63i76e2ljj6@ws.net.home> (raw)
In-Reply-To: <20220405054836.GA23647@lst.de>
On Tue, Apr 05, 2022 at 07:48:36AM +0200, Christoph Hellwig wrote:
> On Tue, Apr 05, 2022 at 07:46:40AM +0200, Hannes Reinecke wrote:
> > On 4/5/22 07:42, Christoph Hellwig wrote:
> >> On Fri, Apr 01, 2022 at 11:28:55AM +0200, Hannes Reinecke wrote:
> >>> It is really annoying to always have to loop through the entire
> >>> /sys/block directory just to find the namespace path links for
> >>> a single namespace in libnvme/nvme-cli.
> >>> So provide links to the namespace paths for efficient lookup.
> >>
> >> I think having some form of links would be useful. Quite a while ago
> >> Thadeu looked into adding some form of relationship for lsblk and
> >> friends. Maybe it would be good to sync up and make sure whatever
> >> links we are adding would be useful for all users?
> >>
> > Care to elaborate?
> > Using the block device name is the most straightforward way here; we don't
> > have a good enumeration to leverage as the paths are essentially just a
> > linked list.
> >
> > We sure can have a subdirectory 'paths', and stick the links in there.
> > If that helps with lsblk ...
>
> I personally don't care. But I've added Thadeu and the util-linux list
> to get everyone on board.
lsblk internally can accept arbitrary relations between devices
(and libsmartcols can display it). If you introduce something new or
extend the current holders/slaves, it will probably be accessible for
lsblk to use it.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
next prev parent reply other threads:[~2022-04-25 13:54 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-01 9:28 [PATCH] nvme: add namespace paths links Hannes Reinecke
2022-04-05 5:42 ` Christoph Hellwig
2022-04-05 5:46 ` Hannes Reinecke
2022-04-05 5:48 ` Christoph Hellwig
2022-04-05 8:34 ` Sagi Grimberg
2022-04-05 9:51 ` Hannes Reinecke
2022-04-05 10:22 ` Sagi Grimberg
2022-04-25 13:54 ` Karel Zak [this message]
2022-07-29 11:43 ` Hannes Reinecke
2023-09-08 6:57 Hannes Reinecke
2023-09-12 11:43 ` Sagi Grimberg
2023-09-12 11:51 ` Hannes Reinecke
2023-09-12 12:55 ` Sagi Grimberg
2023-09-12 14:04 ` Hannes Reinecke
2023-12-04 10:25 ` Sagi Grimberg
2023-12-04 11:19 ` Hannes Reinecke
2023-12-04 11:58 ` Sagi Grimberg
2023-12-08 15:34 ` Daniel Wagner
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=20220425135409.zov6h63i76e2ljj6@ws.net.home \
--to=kzak@redhat.com \
--cc=cascardo@canonical.com \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
--cc=util-linux@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 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.