Re: [RFC dlm/next 09/12] kobject: export generic helper ops

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx>




[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux