From: "Matias Bjørling" <m@bjorling.me>
To: Dan Williams <dan.j.williams@gmail.com>
Cc: Jens Axboe <axboe@kernel.dk>,
Christoph Hellwig <hch@infradead.org>,
Keith Busch <keith.busch@intel.com>,
Simon Lund <slund@cnexlabs.com>,
linux-block@vger.kernel.org
Subject: Re: gendisk and lightnvm
Date: Thu, 26 May 2016 20:10:53 +0200 [thread overview]
Message-ID: <57473C2D.2060700@bjorling.me> (raw)
In-Reply-To: <CAA9_cmfVKoEw1XpJJ4j4+QHWB29-cRvdDp1hmtyegxSpBy0fNw@mail.gmail.com>
On 05/26/2016 07:40 PM, Dan Williams wrote:
> On Mon, May 23, 2016 at 12:24 AM, Matias Bjørling <m@bjorling.me> wrote:
>> Hi Jens, Christoph, and Keith,
>>
>> I have been pondering for a couple of weeks on how to integrate lightnvm
>> into the sysfs stack. Lightnvm does not currently expose a "physical"
>> device. During device registration, the block device name is simply stored,
>> which the user may then use as an id later, and expose through a target
>> implementation.
>>
>> Until then, the device is left "dangling" in the kernel, without any good
>> way to reference it other than asking the lightnvm manager. This also
>> includes device driver specific configuration, such as power and mq sysfs
>> entries.
>>
>> It would be great to have a common way to expose the lightnvm subsystem
>> through the block storage stack.
>>
>> With block devices, the device driver centric information includes:
>>
>> /sys/block/*/
>> inflight
>> removable
>> serial
>> /mq
>> /power
>
> Which of these attributes do you need to access before the device is live?
>
Hi Dan,
/mq would be great. That would make possible to know the status of the
NVMe queues when used by targets. With the current design, the NVMe
driver /mq is never exposed through sysfs, and the targets that exposes
itself as a block device initializes their private genhd.
>> Simon has currently built an RFC patch that wires lightnvm devices up in
>> /sys/devices/virtual/misc/lightnvm/*, without any access to the above
>> entries.
>
> This seems inverted, shouldn't lightnvm be a child of the device +
> driver that uses the api?
>
It could. It is placed above to allow multiple targets (FTLs) on top of
a device, or a target can be across many drives.
next prev parent reply other threads:[~2016-05-26 18:10 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-23 7:24 gendisk and lightnvm Matias Bjørling
2016-05-26 17:40 ` Dan Williams
2016-05-26 18:10 ` Matias Bjørling [this message]
2016-05-26 19:05 ` Dan Williams
2016-05-26 21:50 ` Matias Bjørling
2016-05-26 22:06 ` Dan Williams
2016-05-27 17:25 ` Matias Bjørling
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=57473C2D.2060700@bjorling.me \
--to=m@bjorling.me \
--cc=axboe@kernel.dk \
--cc=dan.j.williams@gmail.com \
--cc=hch@infradead.org \
--cc=keith.busch@intel.com \
--cc=linux-block@vger.kernel.org \
--cc=slund@cnexlabs.com \
/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.