On Thu, 29 Nov 2007 21:26:40 +0100,
Kay Sievers <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-11-29 at 21:20 +0100, Kay Sievers wrote:
> > On Thu, 2007-11-29 at 15:09 -0500, Alan Stern wrote:
> > > On Thu, 29 Nov 2007, Kay Sievers wrote:
>
> > > > > There's another good reason for not assigning the
On Thu, 29 Nov 2007 21:26:40 +0100,
Kay Sievers [EMAIL PROTECTED] wrote:
On Thu, 2007-11-29 at 21:20 +0100, Kay Sievers wrote:
On Thu, 2007-11-29 at 15:09 -0500, Alan Stern wrote:
On Thu, 29 Nov 2007, Kay Sievers wrote:
There's another good reason for not assigning the name in
On Thu, 2007-11-29 at 21:20 +0100, Kay Sievers wrote:
> On Thu, 2007-11-29 at 15:09 -0500, Alan Stern wrote:
> > On Thu, 29 Nov 2007, Kay Sievers wrote:
> > > > There's another good reason for not assigning the name in
> > > > kobject_init(): Code that uses kobjects (like the driver core) doesn't
On Thu, 2007-11-29 at 15:09 -0500, Alan Stern wrote:
> On Thu, 29 Nov 2007, Kay Sievers wrote:
>
> > > My conclusion is different. We should make kobject_init() not consume
> > > any resources at all; just initialize various fields. That way it
> > > would be okay to call either kfree() or
On Thu, 29 Nov 2007, Kay Sievers wrote:
> > My conclusion is different. We should make kobject_init() not consume
> > any resources at all; just initialize various fields. That way it
> > would be okay to call either kfree() or kobject_put() on an initialized
> > kobject. And then when
On Thu, 2007-11-29 at 14:05 -0500, Alan Stern wrote:
> On Thu, 29 Nov 2007, Kay Sievers wrote:
>
> > Your error scenario confirmed my initial concern about suggesting
> > kobject_put() to clean up an initialized kobject.
> >
> > We should probably make kobject_cleanup() free only the resources
On Thu, 29 Nov 2007, Kay Sievers wrote:
> Your error scenario confirmed my initial concern about suggesting
> kobject_put() to clean up an initialized kobject.
>
> We should probably make kobject_cleanup() free only the resources taken
> by kobject_init(), and use kobject_cleanup() instead of
On Thu, 2007-11-29 at 13:04 -0500, Alan Stern wrote:
> On Thu, 29 Nov 2007, Kay Sievers wrote:
>
> > > > Sounds fine, maybe we should also pass the name along, so it will be
> > > > obvious what happens here:
> > > > int kobject_init(struct kobject *kobj, struct kobj_type *type, const
> > > >
On Thu, 29 Nov 2007, Kay Sievers wrote:
> > > Sounds fine, maybe we should also pass the name along, so it will be
> > > obvious what happens here:
> > > int kobject_init(struct kobject *kobj, struct kobj_type *type, const
> > > char *fmt, ...)
> >
> > I don't know... Normally *_init()
On Thu, 2007-11-29 at 12:06 -0500, Alan Stern wrote:
> On Thu, 29 Nov 2007, Kay Sievers wrote:
>
> > > In fact, if we were designing the kobject API from scratch, I'd suggest
> > > making the ktype value an argument to kobject_init() so that it
> > > _couldn't_ be omitted.
> >
> > Sounds fine,
On Thu, 29 Nov 2007, Kay Sievers wrote:
> > In fact, if we were designing the kobject API from scratch, I'd suggest
> > making the ktype value an argument to kobject_init() so that it
> > _couldn't_ be omitted.
>
> Sounds fine, maybe we should also pass the name along, so it will be
> obvious
On Thu, 29 Nov 2007 17:04:40 +0100,
Kay Sievers <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-11-29 at 10:54 -0500, Alan Stern wrote:
> > On Thu, 29 Nov 2007, Kay Sievers wrote:
> >
> > > > And if someone calls kobject_put() after kobject_init() to clean up,
> > > > their release function will not
On Thu, 2007-11-29 at 10:54 -0500, Alan Stern wrote:
> On Thu, 29 Nov 2007, Kay Sievers wrote:
>
> > > And if someone calls kobject_put() after kobject_init() to clean up,
> > > their release function will not be called if they didn't set the ktype.
> > > So the check really belongs into
On Thu, 29 Nov 2007, Kay Sievers wrote:
> > And if someone calls kobject_put() after kobject_init() to clean up,
> > their release function will not be called if they didn't set the ktype.
> > So the check really belongs into kobject_init() IMO.
Right. And even though cleaning up no longer
On Thu, 29 Nov 2007 11:59:06 +0100,
Kay Sievers <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-11-29 at 11:05 +0100, Cornelia Huck wrote:
> > On Wed, 28 Nov 2007 17:00:57 -0500 (EST),
> > Alan Stern <[EMAIL PROTECTED]> wrote:
> > > On Wed, 28 Nov 2007, Greg KH wrote:
> > > > On Wed, Nov 28, 2007 at
On Thu, 2007-11-29 at 11:05 +0100, Cornelia Huck wrote:
> On Wed, 28 Nov 2007 17:00:57 -0500 (EST),
> Alan Stern <[EMAIL PROTECTED]> wrote:
> > On Wed, 28 Nov 2007, Greg KH wrote:
> > > On Wed, Nov 28, 2007 at 03:42:00PM -0500, Alan Stern wrote:
> > > > This patch (as1020) adds a check to
On Wed, 28 Nov 2007 17:00:57 -0500 (EST),
Alan Stern <[EMAIL PROTECTED]> wrote:
> On Wed, 28 Nov 2007, Greg KH wrote:
>
> > On Wed, Nov 28, 2007 at 03:42:00PM -0500, Alan Stern wrote:
> > > This patch (as1020) adds a check to kobject_init() to insure that the
> > > ktype field is not NULL. This
On Wed, 28 Nov 2007 17:00:57 -0500 (EST),
Alan Stern [EMAIL PROTECTED] wrote:
On Wed, 28 Nov 2007, Greg KH wrote:
On Wed, Nov 28, 2007 at 03:42:00PM -0500, Alan Stern wrote:
This patch (as1020) adds a check to kobject_init() to insure that the
ktype field is not NULL. This is just for
On Thu, 2007-11-29 at 11:05 +0100, Cornelia Huck wrote:
On Wed, 28 Nov 2007 17:00:57 -0500 (EST),
Alan Stern [EMAIL PROTECTED] wrote:
On Wed, 28 Nov 2007, Greg KH wrote:
On Wed, Nov 28, 2007 at 03:42:00PM -0500, Alan Stern wrote:
This patch (as1020) adds a check to kobject_init() to
On Thu, 29 Nov 2007 11:59:06 +0100,
Kay Sievers [EMAIL PROTECTED] wrote:
On Thu, 2007-11-29 at 11:05 +0100, Cornelia Huck wrote:
On Wed, 28 Nov 2007 17:00:57 -0500 (EST),
Alan Stern [EMAIL PROTECTED] wrote:
On Wed, 28 Nov 2007, Greg KH wrote:
On Wed, Nov 28, 2007 at 03:42:00PM -0500,
On Thu, 29 Nov 2007, Kay Sievers wrote:
And if someone calls kobject_put() after kobject_init() to clean up,
their release function will not be called if they didn't set the ktype.
So the check really belongs into kobject_init() IMO.
Right. And even though cleaning up no longer needs to
On Thu, 2007-11-29 at 10:54 -0500, Alan Stern wrote:
On Thu, 29 Nov 2007, Kay Sievers wrote:
And if someone calls kobject_put() after kobject_init() to clean up,
their release function will not be called if they didn't set the ktype.
So the check really belongs into kobject_init() IMO.
On Thu, 29 Nov 2007 17:04:40 +0100,
Kay Sievers [EMAIL PROTECTED] wrote:
On Thu, 2007-11-29 at 10:54 -0500, Alan Stern wrote:
On Thu, 29 Nov 2007, Kay Sievers wrote:
And if someone calls kobject_put() after kobject_init() to clean up,
their release function will not be called if
On Thu, 29 Nov 2007, Kay Sievers wrote:
In fact, if we were designing the kobject API from scratch, I'd suggest
making the ktype value an argument to kobject_init() so that it
_couldn't_ be omitted.
Sounds fine, maybe we should also pass the name along, so it will be
obvious what
On Thu, 2007-11-29 at 12:06 -0500, Alan Stern wrote:
On Thu, 29 Nov 2007, Kay Sievers wrote:
In fact, if we were designing the kobject API from scratch, I'd suggest
making the ktype value an argument to kobject_init() so that it
_couldn't_ be omitted.
Sounds fine, maybe we
On Thu, 29 Nov 2007, Kay Sievers wrote:
Sounds fine, maybe we should also pass the name along, so it will be
obvious what happens here:
int kobject_init(struct kobject *kobj, struct kobj_type *type, const
char *fmt, ...)
I don't know... Normally *_init() routines can't fail,
On Thu, 2007-11-29 at 13:04 -0500, Alan Stern wrote:
On Thu, 29 Nov 2007, Kay Sievers wrote:
Sounds fine, maybe we should also pass the name along, so it will be
obvious what happens here:
int kobject_init(struct kobject *kobj, struct kobj_type *type, const
char *fmt, ...)
On Thu, 29 Nov 2007, Kay Sievers wrote:
Your error scenario confirmed my initial concern about suggesting
kobject_put() to clean up an initialized kobject.
We should probably make kobject_cleanup() free only the resources taken
by kobject_init(), and use kobject_cleanup() instead of
On Thu, 2007-11-29 at 14:05 -0500, Alan Stern wrote:
On Thu, 29 Nov 2007, Kay Sievers wrote:
Your error scenario confirmed my initial concern about suggesting
kobject_put() to clean up an initialized kobject.
We should probably make kobject_cleanup() free only the resources taken
by
On Thu, 29 Nov 2007, Kay Sievers wrote:
My conclusion is different. We should make kobject_init() not consume
any resources at all; just initialize various fields. That way it
would be okay to call either kfree() or kobject_put() on an initialized
kobject. And then when something like
On Thu, 2007-11-29 at 15:09 -0500, Alan Stern wrote:
On Thu, 29 Nov 2007, Kay Sievers wrote:
My conclusion is different. We should make kobject_init() not consume
any resources at all; just initialize various fields. That way it
would be okay to call either kfree() or kobject_put()
On Thu, 2007-11-29 at 21:20 +0100, Kay Sievers wrote:
On Thu, 2007-11-29 at 15:09 -0500, Alan Stern wrote:
On Thu, 29 Nov 2007, Kay Sievers wrote:
There's another good reason for not assigning the name in
kobject_init(): Code that uses kobjects (like the driver core) doesn't
set
On Wed, Nov 28, 2007 at 05:00:57PM -0500, Alan Stern wrote:
> On Wed, 28 Nov 2007, Greg KH wrote:
>
> > On Wed, Nov 28, 2007 at 03:42:00PM -0500, Alan Stern wrote:
> > > This patch (as1020) adds a check to kobject_init() to insure that the
> > > ktype field is not NULL. This is just for safety's
On Wed, 28 Nov 2007, Greg KH wrote:
> On Wed, Nov 28, 2007 at 03:42:00PM -0500, Alan Stern wrote:
> > This patch (as1020) adds a check to kobject_init() to insure that the
> > ktype field is not NULL. This is just for safety's sake; as far as I
> > know there are no remaining places where the
On Wed, Nov 28, 2007 at 03:42:00PM -0500, Alan Stern wrote:
> This patch (as1020) adds a check to kobject_init() to insure that the
> ktype field is not NULL. This is just for safety's sake; as far as I
> know there are no remaining places where the field is left unset. But
> ironically,
On Wed, 2007-11-28 at 15:42 -0500, Alan Stern wrote:
> This patch (as1020) adds a check to kobject_init() to insure that the
> ktype field is not NULL.
That's good.
> This is just for safety's sake; as far as I
> know there are no remaining places where the field is left unset. But
>
This patch (as1020) adds a check to kobject_init() to insure that the
ktype field is not NULL. This is just for safety's sake; as far as I
know there are no remaining places where the field is left unset. But
ironically, kset_init() did fail to set it! The patch fixes that and
removes some
On Wed, 2007-11-28 at 15:42 -0500, Alan Stern wrote:
This patch (as1020) adds a check to kobject_init() to insure that the
ktype field is not NULL.
That's good.
This is just for safety's sake; as far as I
know there are no remaining places where the field is left unset. But
ironically,
This patch (as1020) adds a check to kobject_init() to insure that the
ktype field is not NULL. This is just for safety's sake; as far as I
know there are no remaining places where the field is left unset. But
ironically, kset_init() did fail to set it! The patch fixes that and
removes some
On Wed, 28 Nov 2007, Greg KH wrote:
On Wed, Nov 28, 2007 at 03:42:00PM -0500, Alan Stern wrote:
This patch (as1020) adds a check to kobject_init() to insure that the
ktype field is not NULL. This is just for safety's sake; as far as I
know there are no remaining places where the field is
On Wed, Nov 28, 2007 at 03:42:00PM -0500, Alan Stern wrote:
This patch (as1020) adds a check to kobject_init() to insure that the
ktype field is not NULL. This is just for safety's sake; as far as I
know there are no remaining places where the field is left unset. But
ironically, kset_init()
On Wed, Nov 28, 2007 at 05:00:57PM -0500, Alan Stern wrote:
On Wed, 28 Nov 2007, Greg KH wrote:
On Wed, Nov 28, 2007 at 03:42:00PM -0500, Alan Stern wrote:
This patch (as1020) adds a check to kobject_init() to insure that the
ktype field is not NULL. This is just for safety's sake; as
42 matches
Mail list logo
