On Fri, Nov 30, 2007 at 06:22:37PM -0500, Alan Stern wrote:
> On Fri, 30 Nov 2007, Greg KH wrote:
> > And you
> > can't know that, so you have to call kobject_put() in order to be safe
> > and clean up everything.
> >
> > Now why did we not do the final kobject_put() in kobject_del() as well?
> >
On Fri, 30 Nov 2007, Greg KH wrote:
> > However if kobject_add() is never called, or if it is called and it
> > fails, then it's okay to use kfree(). It's not clear whether this
> > distinction will matter in practice. It's probably best to document
> > this using your stronger description.
>
On Fri, Nov 30, 2007 at 05:10:33PM -0500, Alan Stern wrote:
> On Fri, 30 Nov 2007, Greg KH wrote:
>
> > Ok, how about this:
> > void kobject_init(struct kobject *kobj, struct ktype *ktype);
> >
> > and then:
> > int kobject_add(struct kobject *kobj, struct kobject *parent, const
> > char
On Fri, Nov 30, 2007 at 05:10:33PM -0500, Alan Stern wrote:
> On Fri, 30 Nov 2007, Greg KH wrote:
>
> > Ok, how about this:
> > void kobject_init(struct kobject *kobj, struct ktype *ktype);
> >
> > and then:
> > int kobject_add(struct kobject *kobj, struct kobject *parent, const
> > char
On Fri, 30 Nov 2007, Greg KH wrote:
> Ok, how about this:
> void kobject_init(struct kobject *kobj, struct ktype *ktype);
>
> and then:
> int kobject_add(struct kobject *kobj, struct kobject *parent, const
> char *fmt, ...);
>
> After we call kobject_init() we HAVE to call kobject_p
On Fri, Nov 30, 2007 at 04:19:53PM -0500, Alan Stern wrote:
> On Fri, 30 Nov 2007, Greg KH wrote:
>
> > > My suggestion: Have kobject_init_ng() accept a ktype pointer but not a
> > > parent or name. Instead, make kobject_add_ng() take the parent and
> > > name (possibly a kset also). Then when
On Fri, 30 Nov 2007, Greg KH wrote:
> > My suggestion: Have kobject_init_ng() accept a ktype pointer but not a
> > parent or name. Instead, make kobject_add_ng() take the parent and
> > name (possibly a kset also). Then when kobject_init_and_add()
> > encounters an error, it shouldn't do a _p
On Fri, Nov 30, 2007 at 01:04:20PM -0800, Greg KH wrote:
> > My suggestion: Have kobject_init_ng() accept a ktype pointer but not a
> > parent or name. Instead, make kobject_add_ng() take the parent and
> > name (possibly a kset also). Then when kobject_init_and_add()
> > encounters an error,
On Fri, Nov 30, 2007 at 03:25:52PM -0500, Alan Stern wrote:
> On Fri, 30 Nov 2007, Greg KH wrote:
>
> > +/**
> > + * kobject_init_and_add - initialize a kobject structure and add it to the
> > kobject hierarchy
> > + * @kobj: pointer to the kobject to initialize
> > + * @ktype: pointer to the kty
On Fri, 30 Nov 2007, Greg KH wrote:
> +/**
> + * kobject_init_and_add - initialize a kobject structure and add it to the
> kobject hierarchy
> + * @kobj: pointer to the kobject to initialize
> + * @ktype: pointer to the ktype for this kobject.
> + * @parent: pointer to the parent of this kobject.
This is what the kobject_init function is going to become. Add it to
the kernel and then we can convert over the current kobject_init() users
before renaming it.
Also add a kobject_init_and_add function which bundles up what a lot of
the current callers want to do all at once, and it properly han
11 matches
Mail list logo
