[RFC] sysfs kobject that doesn't trigger hotplug events

[RFC] sysfs kobject that doesn't trigger hotplug events

[John Zielinski]

[-- Attachment #1: Type: text/plain, Size: 728 bytes --]

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



[-- Attachment #2: kobject_no_hotplug --]
[-- Type: text/plain, Size: 826 bytes --]

diff -urNX dontdiff linux-2.6.6/include/linux/kobject.h linux/include/linux/kobject.h
--- linux-2.6.6/include/linux/kobject.h	2004-05-09 22:31:59.000000000 -0400
+++ linux/include/linux/kobject.h	2004-05-18 20:29:43.000000000 -0400
@@ -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
--- linux-2.6.6/lib/kobject.c	2004-05-09 22:33:19.000000000 -0400
+++ linux/lib/kobject.c	2004-05-18 20:50:42.000000000 -0400
@@ -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) {

Re: [RFC] sysfs kobject that doesn't trigger hotplug events

[Dmitry Torokhov]

On Tuesday 18 May 2004 09:11 pm, John Zielinski wrote:
> 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.
> 

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

Re: [RFC] sysfs kobject that doesn't trigger hotplug events

[John Zielinski]

Dmitry Torokhov wrote:

> 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. 



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

Re: [RFC] sysfs kobject that doesn't trigger hotplug events

[Greg KH]

On Tue, May 18, 2004 at 10:11:56PM -0400, John Zielinski wrote:
> 
> 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.

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

Re: [RFC] sysfs kobject that doesn't trigger hotplug events

[John Zielinski]

Greg KH wrote:

>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.
>  
>

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

Re: [RFC] sysfs kobject that doesn't trigger hotplug events

[Greg KH]

On Wed, May 19, 2004 at 12:43:47AM -0400, John Zielinski wrote:
> Greg KH wrote:
> 
> >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.
> > 
> >
> 
> You mean this one?
> 
> /* If this kobj does not belong to a kset, try to find a parent that does */

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. */


> 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.

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

> 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?

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

thanks,

greg k-h

Re: [RFC] sysfs kobject that doesn't trigger hotplug events

[John Zielinski]

Greg KH wrote:

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

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.

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


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