All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: Tim Hockin <thockin@sun.com>
Cc: Jeff Garzik <jgarzik@pobox.com>,
	Brad Hards <bhards@bigpond.net.au>,
	Chris Friesen <cfriesen@nortelnetworks.com>,
	Rusty Russell <rusty@rustcorp.com.au>,
	linux-kernel mailing list <linux-kernel@vger.kernel.org>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	cgl_discussion mailing list <cgl_discussion@osdl.org>,
	evlog mailing list <evlog-developers@lists.sourceforge.net>,
	"ipslinux (Keith Mitchell)" <ipslinux@us.ibm.com>,
	Linus Torvalds <torvalds@home.transmeta.com>,
	Hien Nguyen <hien@us.ibm.com>,
	James Keniston <kenistoj@us.ibm.com>,
	Mike Sullivan <sullivam@us.ibm.com>
Subject: Re: alternate event logging proposal
Date: Tue, 24 Sep 2002 17:09:55 -0700	[thread overview]
Message-ID: <3D90FED3.5060705@candelatech.com> (raw)
In-Reply-To: 3D90F78E.1060405@sun.com

Tim Hockin wrote:

> a single device_event file that a daemon reads and dispatches events (I 
> like this one because the daemon is already written, just poorly named - 
> acpid)

Couldn't you just have the message sent to every process that has
opened the file (and have every interested process open the file and
read it in a non-blocking or blocking mode?)

That seems to negate the need for something like acpid, but it does
not preclude it's use.

> 
> For things like netif_carrier, poll() is probably best - the DHCP client 
> can be fully self contained, and not need an eventd to alert it to a 
> signal change.  Of course, acpid does support UNIX socket connections 
> from apps like DHCP....

I would prefer an event, and it can still be self contained if my
idea above is actually workable.

Ben

> 
> 
> 


-- 
Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear



  reply	other threads:[~2002-09-25  0:05 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
2002-09-24 23:38                         ` Tim Hockin
2002-09-25  0:09                           ` Ben Greear [this message]
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=3D90FED3.5060705@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=bhards@bigpond.net.au \
    --cc=cfriesen@nortelnetworks.com \
    --cc=cgl_discussion@osdl.org \
    --cc=evlog-developers@lists.sourceforge.net \
    --cc=hien@us.ibm.com \
    --cc=ipslinux@us.ibm.com \
    --cc=jgarzik@pobox.com \
    --cc=kenistoj@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    --cc=sullivam@us.ibm.com \
    --cc=thockin@sun.com \
    --cc=torvalds@home.transmeta.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.