On Tue, Jun 13, 2023 at 09:34:15AM +0200, Peter Zijlstra wrote:
> On Mon, Jun 12, 2023 at 05:44:59PM +0200, Greg KH wrote:
> > To be fair the end-result of misc_init() is much nicer and cleaner and
> > "obviously correct", which is good, even with the crazy proc file mess
> > in it. So I like the idea overall, need to figure out when to use
> > DEFINE_CLASS() vs. DEFINE_FREE(), that isn't obvious to me.
>
> CLASS is meant for things that have an obvious contructor as well as a
> destructor, that always go together. Like for example the lock things,
> they always pair a lock and unlock. But also things like:
> fdget()+fdput(), these can also always be paired, and if you want the
> file to escape you simply take yet another reference to prevent the
> fdput() from being the final.
Ok, so then the class_destroy stuff down below here should be
DEFINE_CLASS()?
> > @@ -280,29 +268,24 @@ static char *misc_devnode(const struct device *dev, umode_t *mode)
> > return NULL;
> > }
> >
> > +DEFINE_FREE(class_destroy, struct class *, if (_T) class_destroy(_T));
>
> Documentation for class_create() says it will return ERR_PTR(), so then
> this should be something like:
>
> DEFINE_FRERE(class_destroy, struct class *, if (!IS_ERR_OR_NULL(_T)) class_destroy(_T))
Nit, as class_destroy() handles this type of check within it, it can be
even simpler:
DEFINE_FREE(class_destroy, struct class *, class_destroy(_T));
or would that be:
DEFINE_CLASS(class_destroy, struct class *, class_destroy(_T));
?
> > +DEFINE_FREE(remove_proc, struct proc_dir_entry *, if (_T) remove_proc_entry("misc", NULL));
> > static int __init misc_init(void)
> > {
> > + struct proc_dir_entry *ret __free(remove_proc) = proc_create_seq("misc", 0, NULL, &misc_seq_ops);
> > + struct class *c __free(class_destroy) = class_create("misc");
> >
> > + if (IS_ERR(c))
> > + return PTR_ERR(c);
> >
> > if (register_chrdev(MISC_MAJOR, "misc", &misc_fops))
> > + return -EIO;
> >
> > + c->devnode = misc_devnode;
> > +
> > + misc_class = no_free_ptr(c);
> > + no_free_ptr(ret);
> > +
> > + return 0;
> > }
>
> And yes, this does look nicer.
I have a ton of future patches coming that does a bunch of
class_create/destroy changes that would be made a LOT simpler with this
patchset, and I really don't want to have to hit the same codepaths
twice if at all possible.
So what's the odds this can be reasonable enough to get into 6.5-rc1 so
we can rely on it there?
thanks,
greg k-h
