Re: [RFC] New kobject/kset/ktype documentation and example code

On Tue, Nov 27, 2007 at 08:50:14PM -0700, Jonathan Corbet wrote:
Greg KH <greg@xxxxxxxxx> wrote:

Jonathan, I used your old lwn.net article about kobjects as the basis
for this document, I hope you don't mind

Certainly I have no objections, I'm glad it was useful.

Thanks, it was a great framework to work with.

It is rare (even unknown) for kernel code to create a standalone kobject;
with one major exception explained below.

You don't keep this promise - bet you thought we wouldn't notice...
Actually I guess you do, in the "creating simple kobjects" section.
When you get to that point, you should mention that this is a situation
where standalone kobjects make sense.

Sorry, yes, that is where I tried to explain it. I'll flush it out some
more.

Given that there are quite a few standalone kobjects created by this
patch set (kernel_kobj, security_kobj, s390_kobj, etc.), the "(even
unknown)" should probably come out.

Ok.

So, for example, UIO code has a structure that defines the memory region
associated with a uio device:

*The* UIO code, presumably.

fixed.

the given type. So, for example, a pointer to a struct kobject embedded
within a struct cdev called "kp" could be converted to a pointer to the
containing structure with:

That should be "struct uio_mem", I think.

fixed.

one. Calling kobject_init() is not sufficient, however. Kobject users
must, at a minimum, set the name of the kobject; this is the name that will
be used in sysfs entries.

Is setting the name mandatory now, or are there still places where
kobjects (which do not appear in sysfs) do have - and do not need - a
name?

Any kobject that is registered needs to have a name. If someone tries
to call kobject_register() or kobject_add() without a name set they will
find out that it is not allowed :)

And yes, there are a few places in the kernel with kobjects that are
never registered. I'm working on trying to get rid of them...

Because kobjects are dynamic, they must not be declared statically or on
the stack, but instead, always from the heap. Future versions of the

"always be allocated from the heap"?

thanks.

"empty" release function, you will be mocked merciously by the kobject
maintainer if you attempt this.

So just how should severely should we mock kobject maintainers who can't
spell "mercilessly"? :)

Heh, turns out that a lot of people sent me this privately :)

- A kset can provide a set of default attributes that all kobjects that
belong to it automatically inherit and have created whenever a kobject
is registered belonging to the kset.

Can we try that one again?

- A kset can provide a set of default attributes for all kobjects which
belong to it.

No, it's the ktype that does this, I'll go fix that up...

There is currently
no other way to add a kobject to a kset without directly messing with the
list pointers.

Presumably the latter way is not recommended; I would either say so or
not mention this possibility at all.

Ah, yes, now removed.

Thanks for the review, I really appreciate it.

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages