kobject events questions

kobject events questions

[Timo Teräs]

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

Hi all,

I've been following the evolution of kobject events patch. This is 
because I'd like to implement a netfilter target that is able to send an 
event to userland using it.

There's a small description of it and some background in the netfilter 
mailing list:
http://lists.netfilter.org/pipermail/netfilter-devel/2004-August/016342.html

Now that the events are strictly associated with kobjects (the original 
patch had a way to send arbitrary events) I have two choices:

1) Send the events so that they are always associated with the network 
devices class_device kobject. I guess this would be quite clean way to 
do it, but it'd require adding a new signal type and would limit the 
iptables target to be associated always with a interface.

2) Create a device class that has virtual timer devices that trigger 
events (ie. /sys/class/utimer). Each timer could have some attributes 
(like expired, expire_time, etc.) and would emit "change" signals 
whenever timer expires.

I'd like to hear what you think of the thing I'm trying to do?

And especially how "bad" idea the option 2 is (since the new class might 
not be useful for others)?

Any ideas how this could be done better?

- Timo

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: kobject events questions

[Robert Love]

On Wed, 2004-09-29 at 16:37 +0300, Timo Teräs wrote:

> 1) Send the events so that they are always associated with the network 
> devices class_device kobject. I guess this would be quite clean way to 
> do it, but it'd require adding a new signal type and would limit the 
> iptables target to be associated always with a interface.
> 
> 2) Create a device class that has virtual timer devices that trigger 
> events (ie. /sys/class/utimer). Each timer could have some attributes 
> (like expired, expire_time, etc.) and would emit "change" signals 
> whenever timer expires.
> 
> I'd like to hear what you think of the thing I'm trying to do?
> 
> And especially how "bad" idea the option 2 is (since the new class might 
> not be useful for others)?

Well, #1 is the intention and spirit of the kevent system.

And adding a new signal type is fine.

So the only downside is that the table to interface association thing.
I have no idea how big an issue that is for you.

You could of course create a new kobject, ala #2, but that does not seem
optimal if the object is otherwise worthless.  I don't think that you
should create a new class.  Better to put something under /sys/net
related to what you are doing.

	Robert Love

Re: kobject events questions

[Greg KH]

On Wed, Sep 29, 2004 at 04:37:26PM +0300, Timo Ter?s wrote:
> Hi all,
> 
> I've been following the evolution of kobject events patch. This is 
> because I'd like to implement a netfilter target that is able to send an 
> event to userland using it.
> 
> There's a small description of it and some background in the netfilter 
> mailing list:
> http://lists.netfilter.org/pipermail/netfilter-devel/2004-August/016342.html
> 
> Now that the events are strictly associated with kobjects (the original 
> patch had a way to send arbitrary events) I have two choices:
> 
> 1) Send the events so that they are always associated with the network 
> devices class_device kobject. I guess this would be quite clean way to 
> do it, but it'd require adding a new signal type and would limit the 
> iptables target to be associated always with a interface.
> 
> 2) Create a device class that has virtual timer devices that trigger 
> events (ie. /sys/class/utimer). Each timer could have some attributes 
> (like expired, expire_time, etc.) and would emit "change" signals 
> whenever timer expires.
> 
> I'd like to hear what you think of the thing I'm trying to do?

Have you looked at the "connector" patch from Evgeniy Polyakov
<johnpol@2ka.mipt.ru> that was posted to Linux kernel?  After that goes
in, the kevent code will probably be tweaked to use that interface.

thanks,

greg k-h

Re: kobject events questions

[Timo Teräs]

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

Robert Love wrote:
> On Wed, 2004-09-29 at 16:37 +0300, Timo Teräs wrote:
>>1) Send the events so that they are always associated with the network 
>>devices class_device kobject. I guess this would be quite clean way to 
>>do it, but it'd require adding a new signal type and would limit the 
>>iptables target to be associated always with a interface.
>>
>>2) Create a device class that has virtual timer devices that trigger 
>>events (ie. /sys/class/utimer). Each timer could have some attributes 
>>(like expired, expire_time, etc.) and would emit "change" signals 
>>whenever timer expires.
> 
> Well, #1 is the intention and spirit of the kevent system.
> 
> And adding a new signal type is fine.
> 
> So the only downside is that the table to interface association thing.
> I have no idea how big an issue that is for you.

I'm just a bit dubious about adding new signals since they are hardcoded 
in the kernel. It's a time consuming process to add new signals (either 
for development build or for official kernels). This is one of the 
reasons I liked more about the original kevent patch. Wouldn't simple 
#defines have been enough for signal names?

> You could of course create a new kobject, ala #2, but that does not seem
> optimal if the object is otherwise worthless.  I don't think that you
> should create a new class.  Better to put something under /sys/net
> related to what you are doing.

I thought quite a bit about to where add my kobjects. I couldn't find a 
/sys/net on my current system (am I missing some config option?). If you 
mean /sys/class/net aren't all kobject in there supposed to be of same 
type (namely class_device associated with net_device). Of course I could 
add them under some interface, but then again my iptables rules would 
have to be interface specific and this is the thing I'm trying to avoid 
in this approach. Adding to /sys would be an overkill as it'd require 
implementing a subsystem. And I couldn't find any other suitable place 
so ended up making a new class.

I actually made some test code to add a new class and it's relatively 
simple. But I guess it isn't really useful if I'd be the only user. 
Maybe it could have some features that'd make it more generic?

Of course, I could use the "connector" patch that Greg pointed, but I'd 
still like more the kevent approach. Namely, it'd make my userland app 
much simpler.

Cheers,
   Timo

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: kobject events questions

[Greg KH]

On Fri, Oct 01, 2004 at 12:51:51PM +0300, Timo Ter??s wrote:
> Robert Love wrote:
> >On Wed, 2004-09-29 at 16:37 +0300, Timo Ter??s wrote:
> >>1) Send the events so that they are always associated with the network 
> >>devices class_device kobject. I guess this would be quite clean way to 
> >>do it, but it'd require adding a new signal type and would limit the 
> >>iptables target to be associated always with a interface.
> >>
> >>2) Create a device class that has virtual timer devices that trigger 
> >>events (ie. /sys/class/utimer). Each timer could have some attributes 
> >>(like expired, expire_time, etc.) and would emit "change" signals 
> >>whenever timer expires.
> >
> >Well, #1 is the intention and spirit of the kevent system.
> >
> >And adding a new signal type is fine.
> >
> >So the only downside is that the table to interface association thing.
> >I have no idea how big an issue that is for you.
> 
> I'm just a bit dubious about adding new signals since they are hardcoded 
> in the kernel. It's a time consuming process to add new signals (either 
> for development build or for official kernels). This is one of the 
> reasons I liked more about the original kevent patch. Wouldn't simple 
> #defines have been enough for signal names?

What's the difference between a #define and a enum?  We want these to be
well known, and correct.  A enum gives us that.

> >You could of course create a new kobject, ala #2, but that does not seem
> >optimal if the object is otherwise worthless.  I don't think that you
> >should create a new class.  Better to put something under /sys/net
> >related to what you are doing.
> 
> I thought quite a bit about to where add my kobjects. I couldn't find a 
> /sys/net on my current system (am I missing some config option?). If you 
> mean /sys/class/net aren't all kobject in there supposed to be of same 
> type (namely class_device associated with net_device).

Yes, that is what /sys/class/net contains.

Good luck,

greg k-h

Re: kobject events questions

[Teras Timo (EXT-YomiGroup/Helsinki)]

On Fri, Oct 01, 2004 at 09:47:50AM -0700, ext Greg KH wrote:
> > I'm just a bit dubious about adding new signals since they are hardcoded 
> > in the kernel. It's a time consuming process to add new signals (either 
> > for development build or for official kernels). This is one of the 
> > reasons I liked more about the original kevent patch. Wouldn't simple 
> > #defines have been enough for signal names?
> 
> What's the difference between a #define and a enum?  We want these to be
> well known, and correct.  A enum gives us that.

I was a bit ambiguous. I meant #defines with string literals. That would
have assured correct signal names. I guess to have them all well known
justifies for enums (even though it makes adding new ones a bit more
difficult).

Thanks,
  Timo

Re: kobject events questions

[Greg KH]

On Fri, Oct 01, 2004 at 09:47:14PM +0300, Teras Timo (EXT-YomiGroup/Helsinki) wrote:
> On Fri, Oct 01, 2004 at 09:47:50AM -0700, ext Greg KH wrote:
> > > I'm just a bit dubious about adding new signals since they are hardcoded 
> > > in the kernel. It's a time consuming process to add new signals (either 
> > > for development build or for official kernels). This is one of the 
> > > reasons I liked more about the original kevent patch. Wouldn't simple 
> > > #defines have been enough for signal names?
> > 
> > What's the difference between a #define and a enum?  We want these to be
> > well known, and correct.  A enum gives us that.
> 
> I was a bit ambiguous. I meant #defines with string literals. That would
> have assured correct signal names. I guess to have them all well known
> justifies for enums (even though it makes adding new ones a bit more
> difficult).

That's the point.  It should "be difficult" in that you need to present
a valid reason to the whole kernel community as to why a new event needs
to be added.  But if you make a point that others agree with, then there
should be no problem in adding it.

thanks,

greg k-h

Re: kobject events questions

[Timo Teräs]

[-- Attachment #1.1: Type: text/plain, Size: 969 bytes --]

ext Greg KH wrote:
> That's the point.  It should "be difficult" in that you need to present
> a valid reason to the whole kernel community as to why a new event needs
> to be added.  But if you make a point that others agree with, then there
> should be no problem in adding it.

Ok. Now that I can implement my iptables plugin I need either:

1) A new event: something like "went idle". Which would be sent from the 
class_device kobject of related network interface.

or

2) I could use the class interface system to add an kobject (instead of 
writing a new class) for each network devices class_device. But to 
accomplish this I have to be able to register interfaces with net_class 
defined net-sysfs.c. See applied patch. It's provides similar functions 
as scsi layer (see scsi_register_interface).

Which one would be better choice? At least the option #2 is general 
purpose and some others might find it useful too. To whom/where I should 
send it?

- Timo


[-- Attachment #1.2: netdev_interface.diff --]
[-- Type: text/plain, Size: 1061 bytes --]

Index: linux/net/core/net-sysfs.c
===================================================================
--- linux.orig/net/core/net-sysfs.c	2004-09-27 18:27:16.000000000 +0300
+++ linux/net/core/net-sysfs.c	2004-10-06 13:22:07.347392792 +0300
@@ -448,3 +448,11 @@
 {
 	return class_register(&net_class);
 }
+
+int netdev_register_interface(struct class_interface *intf)
+{
+	intf->class = &net_class;
+	return class_interface_register(intf);
+}
+
+EXPORT_SYMBOL_GPL(netdev_register_interface);
Index: linux/include/linux/netdevice.h
===================================================================
--- linux.orig/include/linux/netdevice.h	2004-09-27 18:27:54.000000000 +0300
+++ linux/include/linux/netdevice.h	2004-10-06 13:29:51.031902032 +0300
@@ -953,6 +953,12 @@
 extern char *net_sysctl_strdup(const char *s);
 #endif
 
+#ifdef CONFIG_SYSFS
+extern int netdev_register_interface(struct class_interface *intf);
+#define netdev_unregister_interface(intf) \
+	class_interface_unregister(intf)
+#endif
+
 #endif /* __KERNEL__ */
 
 #endif	/* _LINUX_DEV_H */

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]