Difference between dynamically creating kobject using kobject_create_and_add and kobject_init_and_add function

Question

What is difference between dynamically creating kobject using kobject_create_and_add and kobject_init_and_add function?

kobject_create_and_add allocates a new kobject, while kobject_init_and_add initialize and the kobject passed to it.

struct uio_mem {
struct kobject kobj;
unsigned long addr;
unsigned long size;
int memtype;
void __iomem *internal_addr;
};

I want to use uio_mem in my show and store function, can i Use kobject_create_and_add?

static ssize_t test_attr_show(struct kobject *kobj, struct kobj_attribute *attr,

Is it possible to get uio_mem from the kobj?

Answer 1

I know that this question is a bit old but anyway I wanted to answer it (it may be helpful for other people in the future).

First of all: kobjects are really well described (as a fundamental kernel structure) in ldd.3 (Ch14) as well as in documentation (https://lwn.net/Articles/54651/, http://lwn.net/Articles/51437/). Below I provide a shortcut based on these sources and my understanding. For more details please use these sources and kernel code.

Let's start from the end: why do we need kobjects? They are kernel structures that provide way to implement inheritance for Linux drivers. Each driver related to sysfs should handle reference to kobject (you can think about it as a common ancestor).

The way how that is implemented: kobject needs to be embedded inside the driver structure (in your case struct uio_mem).

Code that works with kobjects often has the opposite problem: given a struct kobject pointer, what is the pointer to the containing structure? In general programming tricks such as manipulation of object should be avoided and, instead use a container_of macro.

The way to convert a pointer to a struct kobject called kp embedded within a struct uio_struct would be:

// container_of(pointer, type, member)
struct cdev *uio_struct = container_of(kp, struct uio_struct, kobj);

Also with attributes by themself, you can find show/store function that didn't give you any kobject.

A good example that I have in mind is virtio driver: see http://lxr.free-electrons.com/source/drivers/virtio/virtio.c?v=3.7

To answer your first question, we need to explain why we need kobject_create and kobject_init?

Main reason is that to run kobject_init you need to make sure that all fields are filled by zeros if that is not the case bad things can happen. Function kobject_create doesn't have this issue: in implementation, it creates object using kzalloc and then adds it. As I understand this function it is safer than init, but I don't see there a bigger difference between the two from a functional perspective.

Another thing to consider is dependencies between objects (if you have a different dependent kobject in your driver), then make sense to use first of all init and then create other objects see for example iommu_group_alloc (by using kobject_create_and_add you won't get any attributes by default but will be like parent/folder, init will create attributes by ktype)