Date: Wed, 27 Apr 2016 12:00:23 -0700
From: Greg KH <gregkh@linuxfoundation.org>
To: Matias =?iso-8859-1?Q?Bj=F8rling?= <mb@lightnvm.io>
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
Message-ID: <20160427190023.GA25619@kroah.com>
References: <1461777537-8145-1-git-send-email-slund@cnexlabs.com>
 <1461777537-8145-2-git-send-email-slund@cnexlabs.com>
 <20160427174137.GA10513@kroah.com>
 <572102F1.3060007@lightnvm.io>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <572102F1.3060007@lightnvm.io>
User-Agent: Mutt/1.6.0 (2016-04-01)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2374
Lines: 77

On Wed, Apr 27, 2016 at 08:20:33PM +0200, Matias Bj?rling wrote:
> 
> 
> 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.

But you could register it with sysfs at this point in time, giving you
a place in the device tree.  Which would be good.

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

Then move the device at this point in time.

> This might not be the ideal way. I like your input on what would be the
> proper way to expose such a device.

See above.

thanks,

greg k-h