All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tim Hockin <thockin@sun.com>
To: Brad Hards <bhards@bigpond.net.au>
Cc: Jeff Garzik <jgarzik@pobox.com>,
	Chris Friesen <cfriesen@nortelnetworks.com>,
	linux-kernel mailing list <linux-kernel@vger.kernel.org>,
	cgl_discussion mailing list <cgl_discussion@osdl.org>,
	evlog mailing list <evlog-developers@lists.sourceforge.net>
Subject: Re: alternate event logging proposal
Date: Tue, 24 Sep 2002 16:59:24 -0700	[thread overview]
Message-ID: <3D90FC5C.9090807@sun.com> (raw)
In-Reply-To: 200209250937.20887.bhards@bigpond.net.au

Brad Hards wrote:

>>You really want something where a userspace app can sleep on an fd, to
>>be awakened when link changes (or some other interesting event occurs)
> 
> Maybe - I've been thinking of a "hotplug" daemon, that can take notifications 
> from the kernel _and_ from other userspace apps. The integrated solution 
> somehow needs to incorporate device hotplugging (eg USB, PCI), network device 
> events (netlink), userspace reconfiguration (eg X colour depth and 
> resolution) and maybe network infrastructure (external to the machine, 
> probably SLPv2 or similar), and reconfigure kernel and applications to match.

See my previous about acpid - it is capable of most of this.  In short:

Open kernel event file
read config files: map regexes to actions
open a named UNIX socket
while 1
	wait for event or data on socket
	if it's an event {
		read event
		for each config'ed regex {
			if it matches this event
				run the associated action
		}
		for each UNIX connection {
			notify the connection of the event
		}
	} else if it's a connection on the socket {
		add the connection to the list of notifications
	}
}


Now it would be easy to make UNIX-connecting apps specify one or more 
regexes, instead of getting broadcasted.  It would be similarly easy to 
make it read multiple sources and handle that - acpi, dev_events, 
user_events (UNIX socket or FIFO).

http://acpid.sourceforge.net  - it's kind of stale, because it does 
everything it needs to do for now :)  It's small, well tested and easy 
to understand.  Best of all, it's already written.

Tim
-- 
Tim Hockin
Systems Software Engineer
Sun Microsystems, Linux Kernel Engineering
thockin@sun.com


  reply	other threads:[~2002-09-24 23:54 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-24  1:54 [PATCH-RFC} 3 of 4 - New problem logging macros, plus template generation Larry Kessler
2002-09-24  2:12 ` Jeff Garzik
2002-09-24  5:47   ` Rusty Russell
2002-09-24  6:05     ` Jeff Garzik
2002-09-24  7:06       ` Rusty Russell
2002-09-24  7:23         ` Jeff Garzik
2002-09-24  7:30           ` Rusty Russell
2002-09-24 19:48             ` alternate event logging proposal Jeff Garzik
2002-09-24 19:57               ` Chris Friesen
2002-09-24 20:03                 ` Jeff Garzik
2002-09-24 20:54                   ` Tim Hockin
2002-09-24 22:32                     ` Brad Hards
2002-09-24 23:31                       ` Jeff Garzik
2002-09-24 23:37                         ` Brad Hards
2002-09-24 23:59                           ` Tim Hockin [this message]
2002-09-24 23:38                         ` Tim Hockin
2002-09-25  0:09                           ` Ben Greear
2002-09-25  0:47                             ` Tim Hockin
2002-09-25  1:14                               ` Brad Hards
2002-09-25  1:38                                 ` Tim Hockin
2002-09-24 20:09                 ` Jeff Garzik
2002-09-24 20:27                   ` [evlog-dev] " Larry Kessler
2002-09-24 20:35                     ` Jeff Garzik
2002-09-24 21:11                       ` Larry Kessler
2002-09-24 21:26                         ` Jeff Garzik
2002-09-25  0:15                           ` Larry Kessler
2002-09-24 21:27                         ` Horst von Brand
2002-09-24 21:50                           ` Larry Kessler
2002-09-25 14:44                 ` Lars Marowsky-Bree
2002-09-24 20:54               ` [evlog-dev] " Daniel E. F. Stekloff
2002-09-24 21:04                 ` Jeff Garzik
2002-09-30 22:43                 ` Pavel Machek

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=3D90FC5C.9090807@sun.com \
    --to=thockin@sun.com \
    --cc=bhards@bigpond.net.au \
    --cc=cfriesen@nortelnetworks.com \
    --cc=cgl_discussion@osdl.org \
    --cc=evlog-developers@lists.sourceforge.net \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    /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.