Re: gendisk and lightnvm

["Matias Bjørling" <m@bjorling.me>]

On 05/26/2016 09:05 PM, Dan Williams wrote:
> On Thu, May 26, 2016 at 11:10 AM, Matias Bjørling <m@bjorling.me> wrote:
>> 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.
>
> 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.