From: "Matias Bjørling" <mb@lightnvm.io>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: "Simon A. F. Lund" <slund@cnexlabs.com>,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] lightnvm: expose configuration through sysfs
Date: Wed, 27 Apr 2016 20:20:33 +0200 [thread overview]
Message-ID: <572102F1.3060007@lightnvm.io> (raw)
In-Reply-To: <20160427174137.GA10513@kroah.com>
On 04/27/2016 07:41 PM, Greg KH wrote:
> On Wed, Apr 27, 2016 at 10:18:57AM -0700, Simon A. F. Lund wrote:
>> --- a/include/linux/lightnvm.h
>> +++ b/include/linux/lightnvm.h
>> @@ -174,6 +174,7 @@ struct nvm_id_group {
>> u16 cpar;
>>
>> struct nvm_id_lp_tbl lptbl;
>> + struct kobject kobj;
>> };
>>
>> struct nvm_addr_format {
>> @@ -205,6 +206,7 @@ struct nvm_target {
>> struct list_head list;
>> struct nvm_tgt_type *type;
>> struct gendisk *disk;
>> + struct kobject kobj;
>> };
>>
>> struct nvm_tgt_instance {
>> @@ -360,6 +362,8 @@ struct nvm_dev {
>>
>> struct mutex mlock;
>> spinlock_t lock;
>> +
>> + struct kobject kobj;
>> };
>>
>> static inline struct ppa_addr generic_to_dev_addr(struct nvm_dev *dev,
>
> Never use "raw" kobjects in a driver for a device. You just guaranteed
> that userspace tools will not see these devices or attributes, which
> implies you didn't really test this using libudev :(
>
> Please use real devices, attached to the real devices your disks already
> have in the tree.
>
> And are you sure you didn't just mess up your reference counting by
> now having the lifecycle of these structures be dictated by the kobject?
>
> thanks,
>
> greg k-h
>
Hi Greg,
Thanks for the feedback.
lightnvm doesn't have anything to hook up with in the /dev/block/* until
a device is exposed through a target. A device goes into a staging area,
and then later is configured to expose a block device.
In the case of NVMe device driver, the driver brings up a device,
identifies it as a lightnvm device, then calls nvm_register and
registers the device. It skips the registration as a block device.
At the nvm_register point, the user can list the available devices
through an ioctl, and then choose a target to put on top. The target
will then expose it as a block device.
This might not be the ideal way. I like your input on what would be the
proper way to expose such a device.
-Matias
next prev parent reply other threads:[~2016-04-27 18:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-27 17:18 [RFC PATCH] lightnvm: expose configuration through sysfs Simon A. F. Lund
2016-04-27 17:18 ` Simon A. F. Lund
2016-04-27 17:41 ` Greg KH
2016-04-27 18:20 ` Matias Bjørling [this message]
2016-04-27 19:00 ` Greg KH
2016-04-27 19:26 ` Matias Bjørling
2016-05-06 16:37 ` Greg KH
2016-05-06 17:41 ` 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=572102F1.3060007@lightnvm.io \
--to=mb@lightnvm.io \
--cc=gregkh@linuxfoundation.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox