On 05/26/2016 09:05 PM, Dan Williams wrote:
On Thu, May 26, 2016 at 11:10 AM, Matias Bjørling <m@xxxxxxxxxxx> wrote:
On 05/26/2016 07:40 PM, Dan Williams wrote:
On Mon, May 23, 2016 at 12:24 AM, Matias Bjørling <m@xxxxxxxxxxx> 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.
Hmm, the queue exists before the gendisk so it seems reasonable to
register/publish mq/ sysfs before the gendisk arrives. I.e. both the
gendisk and the pre-gendisk lightnvm device end up referencing the
same request_queue.
In that case, the holder kobject is maintained by the request queue.
That moves the block device naming earlier in the initialization
process, and the request queue would properly need to hold the (struct
gendisk)->diskname. I wonder if there is a better way.
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
