[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2024081519-caddy-monstrous-b37d@gregkh>
Date: Thu, 15 Aug 2024 07:28:02 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Alexander Aring <aahringo@...hat.com>
Cc: teigland@...hat.com, gfs2@...ts.linux.dev, song@...nel.org,
yukuai3@...wei.com, agruenba@...hat.com, mark@...heh.com,
jlbec@...lplan.org, joseph.qi@...ux.alibaba.com, rafael@...nel.org,
akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
linux-raid@...r.kernel.org, ocfs2-devel@...ts.linux.dev,
lucien.xin@...il.com
Subject: Re: [RFC dlm/next 09/12] kobject: export generic helper ops
On Wed, Aug 14, 2024 at 04:47:28PM -0400, Alexander Aring wrote:
> Hi,
>
> On Wed, Aug 14, 2024 at 11:06 AM Greg KH <gregkh@...uxfoundation.org> wrote:
> >
> > On Wed, Aug 14, 2024 at 10:34:11AM -0400, Alexander Aring wrote:
> > > This patch exports generic helpers like kset_release() and
> > > kset_get_ownership() so users can use them in their own struct kobj_type
> > > implementation instead of implementing their own functions that do the
> > > same.
> >
> > Why is anyone needing these? What raw kobjects require this type of
> > stuff?
> >
>
> In this patch series I introduced kset_type_create_and_add() to have
> the possibility to do the exact same what kset_create_and_add() is
> doing, just setting a different "struct kobj_type", for the kset that
> is created internally by kset_create_and_add(). I can't use
> kset_create_and_add() as it always uses "kset_ktype", see [0].
>
> I am doing that to have only a callback for ".child_ns_type" assigned
> as it returns the "&net_ns_type_operations;" structure to tell
> underneath everything is separated by net namespaces.
> I don't want to change anything else so the "struct kobj_type" should
> look like what kset_create_and_add() is doing. Therefore I am creating
> the same structure as kset_create_and_add() is using, see [0]. The
> "kobj_sysfs_ops" structure seems to be already accessible from
> outside, just the two functions I am exporting in this patch are
> missing. Or I implement it in the same way in the dlm/gfs2 codebase
> (that is what nfs is currently doing, see [1]).
>
> And then we are at the two users of those kobjects that are using
> those functions, it's DLM and GFS2 as they used kset_create_and_add()
> before and I just want to add the ".child_ns_type" callback. Other
> users could be nfs [1] (for the release, get_ownership - I have no
> idea).
Ah, makes much more sense, thanks. And ick, network namespaces...
Anyway, feel free to take this through whatever tree the rest of the
series needs to go through:
Acked-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Powered by blists - more mailing lists