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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.