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. -- 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
