Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1266283 > unrolled thread

Re: [PATCH v10 1/5] configfs: Allow dynamic group creation

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v10 1/5] configfs: Allow dynamic group creation Christoph Hellwig <hch@lst.de> - 2015-11-10 08:00 +0100
    Re: [PATCH v10 1/5] configfs: Allow dynamic group creation Andrew Morton <akpm@linux-foundation.org> - 2015-11-10 22:20 +0100
      Re: [PATCH v10 1/5] configfs: Allow dynamic group creation Jonathan Cameron <jic23@jic23.retrosnub.co.uk> - 2015-11-11 07:50 +0100
        Re: [PATCH v10 1/5] configfs: Allow dynamic group creation Jonathan Cameron <jic23@kernel.org> - 2015-11-15 11:40 +0100
          Re: [PATCH v10 1/5] configfs: Allow dynamic group creation Andrew Morton <akpm@linux-foundation.org> - 2015-11-18 00:50 +0100
            Re: [PATCH v10 1/5] configfs: Allow dynamic group creation Jonathan Cameron <jic23@jic23.retrosnub.co.uk> - 2015-11-18 08:40 +0100
              Re: [PATCH v10 1/5] configfs: Allow dynamic group creation Jonathan Cameron <jic23@kernel.org> - 2015-11-29 18:30 +0100
      Re: [PATCH v10 1/5] configfs: Allow dynamic group creation Joel Becker <jlbec@evilplan.org> - 2015-11-12 00:10 +0100

#1266283 — Re: [PATCH v10 1/5] configfs: Allow dynamic group creation

Andrew,

is this simple addition something you could still send on to Linus
for this merge window?  I would make my life easier to have it in
so I could start using it in patches for various trees in the next
merge window.

Thanks,
	Christoph

On Fri, Oct 23, 2015 at 06:33:27PM +0300, Daniel Baluta wrote:
> We don't want to hardcode default groups at subsystem
> creation time. We export:
> 	* configfs_register_group
> 	* configfs_unregister_group
> to allow drivers to programatically create/destroy groups
> later, after module init time.
> 
> This is needed for IIO configfs support.
> 
> Suggested-by: Lars-Peter Clausen <lars@metafoo.de>
> Signed-off-by: Daniel Baluta <daniel.baluta@intel.com>
> ---
>  fs/configfs/dir.c        | 110 +++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/configfs.h |  10 +++++
>  2 files changed, 120 insertions(+)
> 
> diff --git a/fs/configfs/dir.c b/fs/configfs/dir.c
> index c81ce7f..a7a1b21 100644
> --- a/fs/configfs/dir.c
> +++ b/fs/configfs/dir.c
> @@ -1636,6 +1636,116 @@ const struct file_operations configfs_dir_operations = {
>  	.iterate	= configfs_readdir,
>  };
>  
> +/**
> + * configfs_register_group - creates a parent-child relation between two groups
> + * @parent_group:	parent group
> + * @group:		child group
> + *
> + * link groups, creates dentry for the child and attaches it to the
> + * parent dentry.
> + *
> + * Return: 0 on success, negative errno code on error
> + */
> +int configfs_register_group(struct config_group *parent_group,
> +			    struct config_group *group)
> +{
> +	struct configfs_subsystem *subsys = parent_group->cg_subsys;
> +	struct dentry *parent;
> +	int ret;
> +
> +	mutex_lock(&subsys->su_mutex);
> +	link_group(parent_group, group);
> +	mutex_unlock(&subsys->su_mutex);
> +
> +	parent = parent_group->cg_item.ci_dentry;
> +
> +	mutex_lock_nested(&d_inode(parent)->i_mutex, I_MUTEX_PARENT);
> +	ret = create_default_group(parent_group, group);
> +	if (!ret) {
> +		spin_lock(&configfs_dirent_lock);
> +		configfs_dir_set_ready(group->cg_item.ci_dentry->d_fsdata);
> +		spin_unlock(&configfs_dirent_lock);
> +	}
> +	mutex_unlock(&d_inode(parent)->i_mutex);
> +	return ret;
> +}
> +EXPORT_SYMBOL(configfs_register_group);
> +
> +/**
> + * configfs_unregister_group() - unregisters a child group from its parent
> + * @group: parent group to be unregistered
> + *
> + * Undoes configfs_register_group()
> + */
> +void configfs_unregister_group(struct config_group *group)
> +{
> +	struct configfs_subsystem *subsys = group->cg_subsys;
> +	struct dentry *dentry = group->cg_item.ci_dentry;
> +	struct dentry *parent = group->cg_item.ci_parent->ci_dentry;
> +
> +	mutex_lock_nested(&d_inode(parent)->i_mutex, I_MUTEX_PARENT);
> +	spin_lock(&configfs_dirent_lock);
> +	configfs_detach_prep(dentry, NULL);
> +	spin_unlock(&configfs_dirent_lock);
> +
> +	configfs_detach_group(&group->cg_item);
> +	d_inode(dentry)->i_flags |= S_DEAD;
> +	dont_mount(dentry);
> +	d_delete(dentry);
> +	mutex_unlock(&d_inode(parent)->i_mutex);
> +
> +	dput(dentry);
> +
> +	mutex_lock(&subsys->su_mutex);
> +	unlink_group(group);
> +	mutex_unlock(&subsys->su_mutex);
> +}
> +EXPORT_SYMBOL(configfs_unregister_group);
> +
> +/**
> + * configfs_register_default_group() - allocates and registers a child group
> + * @parent_group:	parent group
> + * @name:		child group name
> + * @item_type:		child item type description
> + *
> + * boilerplate to allocate and register a child group with its parent. We need
> + * kzalloc'ed memory because child's default_group is initially empty.
> + *
> + * Return: allocated config group or ERR_PTR() on error
> + */
> +struct config_group *
> +configfs_register_default_group(struct config_group *parent_group,
> +				const char *name,
> +				struct config_item_type *item_type)
> +{
> +	int ret;
> +	struct config_group *group;
> +
> +	group = kzalloc(sizeof(*group), GFP_KERNEL);
> +	if (!group)
> +		return ERR_PTR(-ENOMEM);
> +	config_group_init_type_name(group, name, item_type);
> +
> +	ret = configfs_register_group(parent_group, group);
> +	if (ret) {
> +		kfree(group);
> +		return ERR_PTR(ret);
> +	}
> +	return group;
> +}
> +EXPORT_SYMBOL(configfs_register_default_group);
> +
> +/**
> + * configfs_unregister_default_group() - unregisters and frees a child group
> + * @group:	the group to act on
> + */
> +void configfs_unregister_default_group(struct config_group *group)
> +{
> +	configfs_unregister_group(group);
> +	kfree(group);
> +}
> +EXPORT_SYMBOL(configfs_unregister_default_group);
> +
>  int configfs_register_subsystem(struct configfs_subsystem *subsys)
>  {
>  	int err;
> diff --git a/include/linux/configfs.h b/include/linux/configfs.h
> index 63a36e8..931ca25 100644
> --- a/include/linux/configfs.h
> +++ b/include/linux/configfs.h
> @@ -252,6 +252,16 @@ static inline struct configfs_subsystem *to_configfs_subsystem(struct config_gro
>  int configfs_register_subsystem(struct configfs_subsystem *subsys);
>  void configfs_unregister_subsystem(struct configfs_subsystem *subsys);
>  
> +int configfs_register_group(struct config_group *parent_group,
> +			    struct config_group *group);
> +void configfs_unregister_group(struct config_group *group);
> +
> +struct config_group *
> +configfs_register_default_group(struct config_group *parent_group,
> +				const char *name,
> +				struct config_item_type *item_type);
> +void configfs_unregister_default_group(struct config_group *group);
> +
>  /* These functions can sleep and can alloc with GFP_KERNEL */
>  /* WARNING: These cannot be called underneath configfs callbacks!! */
>  int configfs_depend_item(struct configfs_subsystem *subsys, struct config_item *target);
> -- 
> 1.9.1
---end quoted text---
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1266789

On Tue, 10 Nov 2015 07:51:26 +0100 Christoph Hellwig <hch@lst.de> wrote:

> is this simple addition something you could still send on to Linus
> for this merge window?  I would make my life easier to have it in
> so I could start using it in patches for various trees in the next
> merge window.

It's super late, but the configfs changes are obviously safe to
existing code.

What about the IIO changes?  Will someone be merging them for 4.5-rc1,
or something else?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1266989

On 10 November 2015 21:12:37 GMT+00:00, Andrew Morton <akpm@linux-foundation.org> wrote:
>On Tue, 10 Nov 2015 07:51:26 +0100 Christoph Hellwig <hch@lst.de>
>wrote:
>
>> is this simple addition something you could still send on to Linus
>> for this merge window?  I would make my life easier to have it in
>> so I could start using it in patches for various trees in the next
>> merge window.
>
>It's super late, but the configfs changes are obviously safe to
>existing code.
>
>What about the IIO changes?  Will someone be merging them for 4.5-rc1,
>or something else?
Yes. I'll take the IIO bits and ultimately they'll go through Greg KH for the 4.5 
merge window.

Jonathan
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1269663

On 11/11/15 06:43, Jonathan Cameron wrote:
> 
> 
> On 10 November 2015 21:12:37 GMT+00:00, Andrew Morton <akpm@linux-foundation.org> wrote:
>> On Tue, 10 Nov 2015 07:51:26 +0100 Christoph Hellwig <hch@lst.de>
>> wrote:
>>
>>> is this simple addition something you could still send on to Linus
>>> for this merge window?  I would make my life easier to have it in
>>> so I could start using it in patches for various trees in the next
>>> merge window.
>>
>> It's super late, but the configfs changes are obviously safe to
>> existing code.
>>
>> What about the IIO changes?  Will someone be merging them for 4.5-rc1,
>> or something else?
> Yes. I'll take the IIO bits and ultimately they'll go through Greg KH for the 4.5 
> merge window.
> 
Hi Andrew,

Just taken a quick look at your mmotm list and see this ended up in the
mainline later group (fair enough given the timing!).
As such shall we fall back to plan b) a special git branch pulled into the trees
of anyone who cares?

I'll base such a tree on some obvious point in Linus' tree (either 4.4 or 4.5-rc1)
That way I can get the IIO stuff queued up asap and we can build on that going
forward during this cycle.

Thanks,

Jonathan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1271743

On Sun, 15 Nov 2015 10:39:08 +0000 Jonathan Cameron <jic23@kernel.org> wrote:

> On 11/11/15 06:43, Jonathan Cameron wrote:
> > 
> > 
> > On 10 November 2015 21:12:37 GMT+00:00, Andrew Morton <akpm@linux-foundation.org> wrote:
> >> On Tue, 10 Nov 2015 07:51:26 +0100 Christoph Hellwig <hch@lst.de>
> >> wrote:
> >>
> >>> is this simple addition something you could still send on to Linus
> >>> for this merge window?  I would make my life easier to have it in
> >>> so I could start using it in patches for various trees in the next
> >>> merge window.
> >>
> >> It's super late, but the configfs changes are obviously safe to
> >> existing code.
> >>
> >> What about the IIO changes?  Will someone be merging them for 4.5-rc1,
> >> or something else?
> > Yes. I'll take the IIO bits and ultimately they'll go through Greg KH for the 4.5 
> > merge window.
> > 
> Hi Andrew,
> 
> Just taken a quick look at your mmotm list and see this ended up in the
> mainline later group (fair enough given the timing!).
> As such shall we fall back to plan b) a special git branch pulled into the trees
> of anyone who cares?
> 
> I'll base such a tree on some obvious point in Linus' tree (either 4.4 or 4.5-rc1)
> That way I can get the IIO stuff queued up asap and we can build on that going
> forward during this cycle.

I plan to send configfs-allow-dynamic-group-creation.patch to Linus
this week.  I'll retain 

iio-core-introduce-iio-configfs-support.patch
iio-core-introduce-iio-software-triggers.patch
iio-core-introduce-iio-software-triggers-fix.patch
iio-trigger-introduce-iio-hrtimer-based-trigger.patch
iio-documentation-add-iio-configfs-documentation.patch

with a view to dropping them once I see them turn up in linux-next.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1271894

On 17 November 2015 23:47:16 GMT+00:00, Andrew Morton <akpm@linux-foundation.org> wrote:
>On Sun, 15 Nov 2015 10:39:08 +0000 Jonathan Cameron <jic23@kernel.org>
>wrote:
>
>> On 11/11/15 06:43, Jonathan Cameron wrote:
>> > 
>> > 
>> > On 10 November 2015 21:12:37 GMT+00:00, Andrew Morton
><akpm@linux-foundation.org> wrote:
>> >> On Tue, 10 Nov 2015 07:51:26 +0100 Christoph Hellwig <hch@lst.de>
>> >> wrote:
>> >>
>> >>> is this simple addition something you could still send on to
>Linus
>> >>> for this merge window?  I would make my life easier to have it in
>> >>> so I could start using it in patches for various trees in the
>next
>> >>> merge window.
>> >>
>> >> It's super late, but the configfs changes are obviously safe to
>> >> existing code.
>> >>
>> >> What about the IIO changes?  Will someone be merging them for
>4.5-rc1,
>> >> or something else?
>> > Yes. I'll take the IIO bits and ultimately they'll go through Greg
>KH for the 4.5 
>> > merge window.
>> > 
>> Hi Andrew,
>> 
>> Just taken a quick look at your mmotm list and see this ended up in
>the
>> mainline later group (fair enough given the timing!).
>> As such shall we fall back to plan b) a special git branch pulled
>into the trees
>> of anyone who cares?
>> 
>> I'll base such a tree on some obvious point in Linus' tree (either
>4.4 or 4.5-rc1)
>> That way I can get the IIO stuff queued up asap and we can build on
>that going
>> forward during this cycle.
>
>I plan to send configfs-allow-dynamic-group-creation.patch to Linus
>this week.  I'll retain 
>
>iio-core-introduce-iio-configfs-support.patch
>iio-core-introduce-iio-software-triggers.patch
>iio-core-introduce-iio-software-triggers-fix.patch
>iio-trigger-introduce-iio-hrtimer-based-trigger.patch
>iio-documentation-add-iio-configfs-documentation.patch
>
>with a view to dropping them once I see them turn up in linux-next.

That's great. Thanks.

Jonathan

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1279381

On 18/11/15 07:33, Jonathan Cameron wrote:
> 
> 
> On 17 November 2015 23:47:16 GMT+00:00, Andrew Morton <akpm@linux-foundation.org> wrote:
>> On Sun, 15 Nov 2015 10:39:08 +0000 Jonathan Cameron <jic23@kernel.org>
>> wrote:
>>
>>> On 11/11/15 06:43, Jonathan Cameron wrote:
>>>>
>>>>
>>>> On 10 November 2015 21:12:37 GMT+00:00, Andrew Morton
>> <akpm@linux-foundation.org> wrote:
>>>>> On Tue, 10 Nov 2015 07:51:26 +0100 Christoph Hellwig <hch@lst.de>
>>>>> wrote:
>>>>>
>>>>>> is this simple addition something you could still send on to
>> Linus
>>>>>> for this merge window?  I would make my life easier to have it in
>>>>>> so I could start using it in patches for various trees in the
>> next
>>>>>> merge window.
>>>>>
>>>>> It's super late, but the configfs changes are obviously safe to
>>>>> existing code.
>>>>>
>>>>> What about the IIO changes?  Will someone be merging them for
>> 4.5-rc1,
>>>>> or something else?
>>>> Yes. I'll take the IIO bits and ultimately they'll go through Greg
>> KH for the 4.5 
>>>> merge window.
>>>>
>>> Hi Andrew,
>>>
>>> Just taken a quick look at your mmotm list and see this ended up in
>> the
>>> mainline later group (fair enough given the timing!).
>>> As such shall we fall back to plan b) a special git branch pulled
>> into the trees
>>> of anyone who cares?
>>>
>>> I'll base such a tree on some obvious point in Linus' tree (either
>> 4.4 or 4.5-rc1)
>>> That way I can get the IIO stuff queued up asap and we can build on
>> that going
>>> forward during this cycle.
>>
>> I plan to send configfs-allow-dynamic-group-creation.patch to Linus
>> this week.  I'll retain 
>>
>> iio-core-introduce-iio-configfs-support.patch
>> iio-core-introduce-iio-software-triggers.patch
>> iio-core-introduce-iio-software-triggers-fix.patch
>> iio-trigger-introduce-iio-hrtimer-based-trigger.patch
>> iio-documentation-add-iio-configfs-documentation.patch
>>
>> with a view to dropping them once I see them turn up in linux-next.
> 
> That's great. Thanks.
I've now applied the rest of the series to my local togreg branch and pushed
out as testing for the autobuilders to play with them.

This branch will get rebased once Greg has picked up the previous PULL request.

Thanks,

Jonathan
> 
> Jonathan
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1267527

On Tue, Nov 10, 2015 at 01:12:37PM -0800, Andrew Morton wrote:
> On Tue, 10 Nov 2015 07:51:26 +0100 Christoph Hellwig <hch@lst.de> wrote:
> 
> > is this simple addition something you could still send on to Linus
> > for this merge window?  I would make my life easier to have it in
> > so I could start using it in patches for various trees in the next
> > merge window.
> 
> It's super late, but the configfs changes are obviously safe to
> existing code.

Loving this change, even if this is merely a drive-by:

Acked-by: Joel Becker <jlbec@evilplan.org>

> 
> What about the IIO changes?  Will someone be merging them for 4.5-rc1,
> or something else?
> 

-- 

"Copy from one, it's plagiarism; copy from two, it's research."
        - Wilson Mizner

			http://www.jlbec.org/
			jlbec@evilplan.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web