sysfs kobject that doesn't trigger hotplug events

I'm adding some data structures to a device and want them to appear under that device in sysfs in subdirectories. These data structures are linked together in a tree like layout so it would make sense to have them have a subdirectory tree representing them. These data structures have a kobject for reference counting and I can use kobject_add and kobject_del to add them to the sysfs tree.

Looking through the kobject.c code I noticed that this would create a lot of hotplug events which would burn up a bit of processor time. These events are not necessary as these are not device kobjects. I've enclosed a patch to my solution for this. I'd like to know if there are any side effects with this method.

John

diff -urNX dontdiff linux-2.6.6/include/linux/kobject.h linux/include/linux/kobject.h
@@ -62,6 +62,7 @@
 	void (*release)(struct kobject *);
 	struct sysfs_ops	* sysfs_ops;
 	struct attribute	** default_attrs;
+	int			no_hotplug;
 };
 
 

diff -urNX dontdiff linux-2.6.6/lib/kobject.c linux/lib/kobject.c
@@ -203,6 +203,9 @@
 {
 	struct kobject * top_kobj = kobj;
 
+	if (kobj->ktype && kobj->ktype->no_hotplug)
+		return;
+
 	/* If this kobj does not belong to a kset,
 	   try to find a parent that does. */
 	if (!top_kobj->kset && top_kobj->parent) {

Your patch is not needed at all. Please read the first comment in the kobject_hotplug() function to see how to prevent kobjects from creating hotplug events.

thanks,

greg k-h

You mean this one?

/* If this kobj does not belong to a kset, try to find a parent that does */

The problem I saw with that is even though my kobject won't have a kset, my kobject's parent (or grandparent) may and I'll trigger that one. I'm not creating a new device driver, just extending one so I won't have control over that kobject's lineage.

The other way is to create a subsystem using subsytem_init but not to add it to the sysfs tree and then add my kobject to that kset and use the kset's hotplug filter to stop the hotplug events. This would require extra code and a little bit more memory usage for that kset, but I believe that would work. Any drawbacks to this method?

Or am I missing something?

John

Oops, sorry, I meant the one in kset_hotplug() which is called by kobject_hotplug() that says:

		/* If the kset has a filter operation, call it. If it
		 * returns failure, no hotplug event is required. */

So why are you creating a kobject, and not just attributes?

What exactly are you wanting to do? How about we start there.

thanks,

greg k-h

So I could reuse the kobjects reference counting code so that my data would get freed once other kernel code no longer referenced it. It would also let me have a more elaborate directory tree instead of just a single subdirectory deep as with attribute groups, kind of like what Stephen Hemminger wanted to do with his bridge device directory layout.

This is for an embedded project I'm working on but the code may be useful once the fbdev guys start expanding their sysfs support. Basically I want to expose the fbdev's modedb structures to user space and have an interface for manipulating this information. I'm expanding that modedb to also include supported color bit formats, etc. Trying to encode the relationships in the attribute filenames would quickly get unmanageable. That's why I want to have a nice directory layout presenting that info.

Now there was a big Holy War (tm) in the fbdev mailing list about whether that should be done in kernel space or user space, but for my project for simplicity I want in in kernel space and I _believe_ the last truce in the fbdev list has it in the kernel as well. :)

John

You are wasting 4 bytes for every kobject out there. Just implement your private hotplug callback that would return something like -ENODEV so the hotplug helper would not be called. If needed you can call kobject_hotplug later, when you are ready.

Dmitry

Actually for every kobj_type structure, not for every kobject. Doing a quick scan through the kernel I found 25 kobj_type decelerations so that would add up to 100 bytes only. And that could be made a byte or flags field.

I wasn't sure if it was possible to create a subsystem that wasn't a part of the sysfs tree that contained kobjects that were. Looking trough the code again it looks like it is so I'll use the hotplug filter as you suggest.

John