All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Timo Teräs" <ext-timo.teras@nokia.com>
To: Robert Love <rml@novell.com>
Cc: Greg KH <greg@kroah.com>, linux-kernel@vger.kernel.org
Subject: Re: kobject events questions
Date: Fri, 01 Oct 2004 12:51:51 +0300	[thread overview]
Message-ID: <415D28B7.5070306@nokia.com> (raw)
In-Reply-To: <1096486749.4666.31.camel@betsy.boston.ximian.com>

[-- 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 --]

  reply	other threads:[~2004-10-01  9:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-29 13:37 kobject events questions Timo Teräs
2004-09-29 19:39 ` Robert Love
2004-10-01  9:51   ` Timo Teräs [this message]
2004-10-01 16:47     ` Greg KH
2004-10-01 18:47       ` Teras Timo (EXT-YomiGroup/Helsinki)
2004-10-01 19:22         ` Greg KH
2004-10-06 10:39           ` Timo Teräs
2004-09-29 23:35 ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=415D28B7.5070306@nokia.com \
    --to=ext-timo.teras@nokia.com \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rml@novell.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.