All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH next 3/3] debugfs: introduce debugfs_create_seq[,_data]
Date: Fri, 29 Nov 2019 23:16:09 +0100	[thread overview]
Message-ID: <20191129221609.GA3710566@kroah.com> (raw)
In-Reply-To: <35da2509-1dc4-699d-e209-b534691f6e37@huawei.com>

On Fri, Nov 29, 2019 at 11:03:47PM +0800, Kefeng Wang wrote:
> 
> 
> On 2019/11/29 22:22, Greg KH wrote:
> > On Fri, Nov 29, 2019 at 05:27:52PM +0800, Kefeng Wang wrote:
> >> Like proc_create_seq[,_data] in procfs, introduce a similar
> >> debugfs_create_seq[,_data] function, which could drastically
> >> reduces the boilerplate code.
> >>
> >> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> >> ---
> >>  fs/debugfs/file.c       | 62 ++++++++++++++++++++++++++++++++++++++++-
> >>  include/linux/debugfs.h | 16 +++++++++++
> >>  2 files changed, 77 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
> >> index 68f0c4b19bef..77522717c9fb 100644
> >> --- a/fs/debugfs/file.c
> >> +++ b/fs/debugfs/file.c
> >> @@ -1107,7 +1107,10 @@ EXPORT_SYMBOL_GPL(debugfs_create_regset32);
> >>  #endif /* CONFIG_HAS_IOMEM */
> >>  
> >>  struct debugfs_entry {
> >> -	int (*read)(struct seq_file *seq, void *data);
> >> +	union {
> >> +		const struct seq_operations *seq_ops;
> >> +		int (*read)(struct seq_file *seq, void *data);
> >> +	};
> >>  	void *data;
> >>  };
> >>  
> >> @@ -1196,3 +1199,60 @@ struct dentry *debugfs_create_single_data(const char *name, umode_t mode,
> >>  				   &debugfs_entry_ops);
> >>  }
> >>  EXPORT_SYMBOL_GPL(debugfs_create_single_data);
> >> +
> >> +static int debugfs_entry_seq_open(struct inode *inode, struct file *file)
> >> +{
> >> +	struct debugfs_entry *entry = inode->i_private;
> >> +	int ret;
> >> +
> >> +	entry = debugfs_clear_lowest_bit(entry);
> >> +
> >> +	ret = seq_open(file, entry->seq_ops);
> >> +	if (!ret && entry->data) {
> >> +		struct seq_file *seq = file->private_data;
> >> +		seq->private = entry->data;
> >> +	}
> >> +
> >> +	return ret;
> >> +}
> >> +
> >> +static const struct file_operations debugfs_seq_fops = {
> >> +	.open		= debugfs_entry_seq_open,
> >> +	.read		= seq_read,
> >> +	.llseek		= seq_lseek,
> >> +	.release	= seq_release,
> >> +};
> >> +
> >> +/**
> >> + * debugfs_create_seq_data - create a file in the debugfs filesystem
> >> + * @name: a pointer to a string containing the name of the file to create.
> >> + * @mode: the permission that the file should have.
> >> + * @parent: a pointer to the parent dentry for this file.  This should be a
> >> + *          directory dentry if set.  If this parameter is NULL, then the
> >> + *          file will be created in the root of the debugfs filesystem.
> >> + * @data: a pointer to something that the caller will want to get to later
> >> + *        on.  The inode.i_private pointer will point to this value on
> >> + *        the open() call.
> >> + * @seq_ops: seq_operations pointer of the seqfile.
> >> + *
> >> + * This function creates a file in debugfs with the extra data and a seq_ops.
> >> + */
> >> +struct dentry *debugfs_create_seq_data(const char *name, umode_t mode,
> >> +				       struct dentry *parent, void *data,
> >> +				       const struct seq_operations *seq_ops)
> >> +{
> >> +	struct debugfs_entry *entry;
> >> +
> >> +	entry = kzalloc(sizeof(*entry), GFP_KERNEL);
> >> +	if (!entry)
> >> +		return ERR_PTR(-ENOMEM);
> >> +
> >> +	entry->seq_ops = seq_ops;
> >> +	entry->data = data;
> >> +
> >> +	entry = debugfs_set_lowest_bit(entry);
> >> +
> >> +	return debugfs_create_file(name, mode, parent, entry,
> >> +				   &debugfs_seq_fops);
> >> +}
> >> +EXPORT_SYMBOL_GPL(debugfs_create_seq_data);
> >> diff --git a/include/linux/debugfs.h b/include/linux/debugfs.h
> >> index 82171f183e93..d32d49983547 100644
> >> --- a/include/linux/debugfs.h
> >> +++ b/include/linux/debugfs.h
> >> @@ -147,6 +147,10 @@ struct dentry *debugfs_create_single_data(const char *name, umode_t mode,
> >>  					  int (*read_fn)(struct seq_file *s,
> >>  							 void *data));
> >>  
> >> +struct dentry *debugfs_create_seq_data(const char *name, umode_t mode,
> >> +				       struct dentry *parent, void *data,
> >> +				       const struct seq_operations *seq_ops);
> >> +
> >>  bool debugfs_initialized(void);
> >>  
> >>  ssize_t debugfs_read_file_bool(struct file *file, char __user *user_buf,
> > 
> > If you notice, I have been removing the return value of the
> > debugfs_create_* functions over the past few kernel versions (look at
> > 5.5-rc1 for a lot more).  Please don't add any new functions that also
> > return a dentry that I then need to go and remove.
> 
> Hi Greg, see function debugfs_create_seq_data()and debugfs_create_single_data(),
> they are wrapper function of debugfs_create_file(), when remove the debugfs file
> called debugfs_remove(), some drivers could do such thing, we must return a dentry
> to the caller.

Again, no, we should not return a dentry.  Files should go in
directories and then removed all at once if they need to, which is why I
have been making these types of changes.

Yes, for some existing files that does not work, but again, please do
not create a new api that does this.  Only use it for the files that do
not need their dentries saved.

thanks,

greg k-h

  reply	other threads:[~2019-11-29 22:16 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-29  9:27 [PATCH next 0/3] debugfs: introduce debugfs_create_single/seq[,_data] Kefeng Wang
2019-11-29  9:27 ` [PATCH next 1/3] debugfs: Provide debugfs_[set|clear|test]_lowest_bit() Kefeng Wang
2019-11-29  9:27 ` [PATCH next 2/3] debugfs: introduce debugfs_create_single[,_data] Kefeng Wang
2019-12-03  8:38   ` [PATCH next 2/3] debugfs: introduce debugfs_create_single[, _data] Dan Carpenter
2019-12-03  8:38     ` [PATCH next 2/3] debugfs: introduce debugfs_create_single[,_data] Dan Carpenter
2019-12-03  8:38     ` [PATCH next 2/3] debugfs: introduce debugfs_create_single[, _data] Dan Carpenter
2019-12-03  9:02     ` [kbuild-all] " Rong Chen
2019-12-03  9:02       ` [kbuild-all] Re: [PATCH next 2/3] debugfs: introduce debugfs_create_single[,_data] Rong Chen
2019-12-03  9:02       ` [PATCH next 2/3] debugfs: introduce debugfs_create_single[, _data] Rong Chen
2019-12-03  9:32       ` [kbuild-all] " Dan Carpenter
2019-12-03  9:32         ` [kbuild-all] Re: [PATCH next 2/3] debugfs: introduce debugfs_create_single[,_data] Dan Carpenter
2019-12-03  9:32         ` [PATCH next 2/3] debugfs: introduce debugfs_create_single[, _data] Dan Carpenter
2019-11-29  9:27 ` [PATCH next 3/3] debugfs: introduce debugfs_create_seq[,_data] Kefeng Wang
2019-11-29 14:22   ` Greg KH
2019-11-29 15:03     ` Kefeng Wang
2019-11-29 22:16       ` Greg KH [this message]
2019-11-29 14:21 ` [PATCH next 0/3] debugfs: introduce debugfs_create_single/seq[,_data] Greg KH
2019-11-29 15:16   ` Kefeng Wang
2019-11-29 22:19     ` Greg KH
2019-11-29 22:23       ` Greg KH

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=20191129221609.GA3710566@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wangkefeng.wang@huawei.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.