| Message ID | 1445614411-533-2-git-send-email-daniel.baluta@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Is this going into 4.4 through the iio tree? If not is there any chance
to get it in through some other tree? While we're not past the merge
window is trivial new functionality that doesn't change code, and I'd like to
move existing configfs users over to it ASAP, so getting it into a baseline
tree ASAP would be immensely helpful.
Oh, and:
Reviewed-by: Christoph Hellwig <hch@lst.de>
(I though we already had that, but oh well)
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Nov 6, 2015 at 9:50 AM, Christoph Hellwig <hch@lst.de> wrote: > Is this going into 4.4 through the iio tree? If not is there any chance > to get it in through some other tree? While we're not past the merge > window is trivial new functionality that doesn't change code, and I'd like to > move existing configfs users over to it ASAP, so getting it into a baseline > tree ASAP would be immensely helpful. I think Jonathan could take this via linux-iio around Sunday. Could anyone do it faster :)? Andrew? > > Oh, and: > > Reviewed-by: Christoph Hellwig <hch@lst.de> I didn't add your Reviewed-by tag because I removed configfs_alloc_group/configfs_free_group functions. Thanks Christoph! -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/06/2015 09:48 AM, Daniel Baluta wrote: > On Fri, Nov 6, 2015 at 9:50 AM, Christoph Hellwig <hch@lst.de> wrote: >> Is this going into 4.4 through the iio tree? If not is there any chance >> to get it in through some other tree? While we're not past the merge >> window is trivial new functionality that doesn't change code, and I'd like to >> move existing configfs users over to it ASAP, so getting it into a baseline >> tree ASAP would be immensely helpful. > > I think Jonathan could take this via linux-iio around Sunday. > Since the IIO tree goes through the staging tree, which is already closed for 4.4, we won't be able to get it into 4.4 through the IIO tree. The whole configfs support for IIO will have to wait for 4.5. > Could anyone do it faster :)? Andrew? -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Nov 06, 2015 at 05:38:53PM +0000, Jonathan Cameron wrote: > Yup. I'd have no objection to a direct request to Linus to take this as a one off. I'd appreciate if you could give it a try. > Or we can do an immutable branch and pull it into all relevant subtrees so all > users can hit mainline all in 4.5 without waiting for a cycle. That tends to work well for bits like this. That would be the second best option. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/11/15 13:09, Christoph Hellwig wrote: > On Fri, Nov 06, 2015 at 05:38:53PM +0000, Jonathan Cameron wrote: >> Yup. I'd have no objection to a direct request to Linus to take this as a one off. > > I'd appreciate if you could give it a try. Unfortunately this would fall out of scope for me to send. The bit we care about is definitely a file system code change in configfs. Whilst the first user will probably be IIO, I can't justify to Linus why it is necessary to put this in place ASAP rather than via normal paths (which in my case is via Greg) If Joel was active I'd suggest it should come from him if we want to try this, as he isn't (as a side note, we should probably update the MAINTAINERS entry to mark it as unmaintained I guess), who ends up being maintainer of last resort for file systems? <quick git log browse later> I'd say you need to make a case to Al Viro or Andrew Morton. > >> Or we can do an immutable branch and pull it into all relevant subtrees so all >> users can hit mainline all in 4.5 without waiting for a cycle. That tends to work well for bits like this. > > That would be the second best option. I can do this easily enough and it's probably my preferred option. 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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? >
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-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 29/11/15 17:27, Jonathan Cameron wrote: > 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. Now rebased - I also made a tiny change to take the iio_configfs_subsys structure static in response to a sparse warning - shout if I've done anything silly. > > Thanks, > > Jonathan >> >> 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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);
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(+)