On 05/26/2016 07:40 PM, Dan Williams wrote:

On Mon, May 23, 2016 at 12:24 AM, Matias Bjørling [off-list ref] wrote:

quoted

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.

quoted

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.