Re: [RFC] New kobject/kset/ktype documentation and example code
- From: corbet@xxxxxxx (Jonathan Corbet)
- Date: Tue, 27 Nov 2007 20:50:14 -0700
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.
A few little things...
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.
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.
So, for example, UIO code has a structure that defines the memory region
associated with a uio device:
*The* UIO code, presumably.
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.
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?
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"?
"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"? :)
- 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.
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.
jon
-
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/
- Follow-Ups:
- References:
- Prev by Date: Re: [PATCH 1/3] Remove trailing NULs from network bonding sysfs interface.
- Next by Date: Re: ACPI related Warning in 2.6.24-rc3-git2
- Previous by thread: Re: [RFC] New kobject/kset/ktype documentation and example code
- Next by thread: Re: [RFC] New kobject/kset/ktype documentation and example code
- Index(es):
Relevant Pages
|
|