linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sourabh Jain <sourabhjain@linux.ibm.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: mpe@ellerman.id.au, mahesh@linux.vnet.ibm.com,
	hbathini@linux.ibm.com, linux-kernel@vger.kernel.org,
	linuxppc-dev@ozlabs.org, corbet@lwn.net,
	linux-doc@vger.kernel.org
Subject: Re: [PATCH v4 2/6] sysfs: wrap __compat_only_sysfs_link_entry_to_kobj function to change the symlink name
Date: Fri, 6 Dec 2019 23:57:53 +0530	[thread overview]
Message-ID: <3aabdf19-ccbf-e99a-c560-2b110e8b536a@linux.ibm.com> (raw)
In-Reply-To: <20191206124642.GB1360047@kroah.com>



On 12/6/19 6:16 PM, Greg KH wrote:
> On Fri, Dec 06, 2019 at 05:54:30PM +0530, Sourabh Jain wrote:
>> The __compat_only_sysfs_link_entry_to_kobj function creates a symlink to a
>> kobject but doesn't provide an option to change the symlink file name.
>>
>> This patch adds a wrapper function create_sysfs_symlink_entry_to_kobj that
>> extends the __compat_only_sysfs_link_entry_to_kobj functionality which
>> allows function caller to customize the symlink name.
>>
>> Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
>> ---
>>  fs/sysfs/group.c      | 28 +++++++++++++++++++++++++---
>>  include/linux/sysfs.h | 12 ++++++++++++
>>  2 files changed, 37 insertions(+), 3 deletions(-)
>>
>> diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
>> index d41c21fef138..5eb38145b957 100644
>> --- a/fs/sysfs/group.c
>> +++ b/fs/sysfs/group.c
>> @@ -424,6 +424,25 @@ EXPORT_SYMBOL_GPL(sysfs_remove_link_from_group);
>>  int __compat_only_sysfs_link_entry_to_kobj(struct kobject *kobj,
>>  				      struct kobject *target_kobj,
>>  				      const char *target_name)
>> +{
>> +	return create_sysfs_symlink_entry_to_kobj(kobj, target_kobj,
>> +						target_name, NULL);
>> +}
>> +EXPORT_SYMBOL_GPL(__compat_only_sysfs_link_entry_to_kobj);
>> +
>> +/**
>> + * create_sysfs_symlink_entry_to_kobj - add a symlink to a kobject pointing
>> + * to a group or an attribute
>> + * @kobj:		The kobject containing the group.
>> + * @target_kobj:	The target kobject.
>> + * @target_name:	The name of the target group or attribute.
>> + * @symlink_name:	The name of the symlink file (target_name will be
>> + *			considered if symlink_name is NULL).
>> + */
>> +int create_sysfs_symlink_entry_to_kobj(struct kobject *kobj,
>> +				       struct kobject *target_kobj,
>> +				       const char *target_name,
>> +				       const char *symlink_name)
>>  {
>>  	struct kernfs_node *target;
>>  	struct kernfs_node *entry;
>> @@ -448,12 +467,15 @@ int __compat_only_sysfs_link_entry_to_kobj(struct kobject *kobj,
>>  		return -ENOENT;
>>  	}
>>  
>> -	link = kernfs_create_link(kobj->sd, target_name, entry);
>> +	if (!symlink_name)
>> +		symlink_name = target_name;
>> +
>> +	link = kernfs_create_link(kobj->sd, symlink_name, entry);
>>  	if (IS_ERR(link) && PTR_ERR(link) == -EEXIST)
>> -		sysfs_warn_dup(kobj->sd, target_name);
>> +		sysfs_warn_dup(kobj->sd, symlink_name);
>>  
>>  	kernfs_put(entry);
>>  	kernfs_put(target);
>>  	return PTR_ERR_OR_ZERO(link);
>>  }
>> -EXPORT_SYMBOL_GPL(__compat_only_sysfs_link_entry_to_kobj);
>> +EXPORT_SYMBOL_GPL(create_sysfs_symlink_entry_to_kobj);
>> diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
>> index 5420817ed317..123c6f10333a 100644
>> --- a/include/linux/sysfs.h
>> +++ b/include/linux/sysfs.h
>> @@ -300,6 +300,10 @@ void sysfs_remove_link_from_group(struct kobject *kobj, const char *group_name,
>>  int __compat_only_sysfs_link_entry_to_kobj(struct kobject *kobj,
>>  				      struct kobject *target_kobj,
>>  				      const char *target_name);
>> +int create_sysfs_symlink_entry_to_kobj(struct kobject *kobj,
>> +				       struct kobject *target_kobj,
>> +				       const char *target_name,
>> +				       const char *symlink_name);
> 
> sysfs_create_symlink_entry_to_kobj()?
> 
> I can't remember why we put __compat_only there, perhaps because we do
> not want people to really use this unless you really really have to?

We don't have much option here. I tried replicating the sysfs files
in older patch series but creating symlink at old location is much
better approach.

The __compat_only_sysfs_link_entry_to_kobj function is pretty generic,
unable to understand the reason behind restricting its usage.

> 
> So then keep compat_only here as well?

Sure, I will rename the wrapper function.

But how about changing the function signature instead of creating
a wrapper function?

Considering the fact that there are only two places this function
has called.

> 
> What breaks if you remove those undocumented sysfs files?  What
> userspace tool do you have that will even notice?

The scripts used in kdump service need those sysfs files to control
the dump collection. So we can't just move the sysfs files to the
new location.

Thanks,
Sourabh Jain


  reply	other threads:[~2019-12-06 18:28 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-06 12:24 [PATCH v4 0/6] reorganize and add FADump sysfs files Sourabh Jain
2019-12-06 12:24 ` [PATCH v4 1/6] Documentation/ABI: add ABI documentation for /sys/kernel/fadump_* Sourabh Jain
2019-12-06 12:47   ` Greg KH
2019-12-06 12:24 ` [PATCH v4 2/6] sysfs: wrap __compat_only_sysfs_link_entry_to_kobj function to change the symlink name Sourabh Jain
2019-12-06 12:46   ` Greg KH
2019-12-06 18:27     ` Sourabh Jain [this message]
2019-12-06 19:14       ` Greg KH
2019-12-07  3:21         ` Sourabh Jain
2019-12-06 12:24 ` [PATCH v4 3/6] powerpc/fadump: reorganize /sys/kernel/fadump_* sysfs files Sourabh Jain
2019-12-06 12:45   ` Greg KH
2019-12-06 19:13     ` Sourabh Jain
2019-12-06 12:24 ` [PATCH v4 4/6] powerpc/powernv: move core and fadump_release_opalcore under new kobject Sourabh Jain
2019-12-06 12:48   ` Greg KH
2019-12-06 19:16     ` Sourabh Jain
2019-12-06 12:24 ` [PATCH v4 5/6] Documentation/ABI: mark /sys/kernel/fadump_* sysfs files deprecated Sourabh Jain
2019-12-06 12:24 ` [PATCH v4 6/6] powerpc/fadump: sysfs for fadump memory reservation Sourabh Jain
2019-12-06 12:48   ` Greg KH
2019-12-06 19:19     ` Sourabh Jain

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=3aabdf19-ccbf-e99a-c560-2b110e8b536a@linux.ibm.com \
    --to=sourabhjain@linux.ibm.com \
    --cc=corbet@lwn.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=hbathini@linux.ibm.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mahesh@linux.vnet.ibm.com \
    --cc=mpe@ellerman.id.au \
    /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;
as well as URLs for NNTP newsgroup(s).