linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kay Sievers <kay.sievers@vrfy.org>
To: linux-hotplug@vger.kernel.org
Subject: Re: udev and dbus
Date: Thu, 11 Mar 2004 18:12:55 +0000	[thread overview]
Message-ID: <1079028775.1127.149.camel@pim> (raw)
In-Reply-To: <20040217214449.GB12411@wonderland.linux.it>

On Thu, 2004-03-11 at 18:41, David Zeuthen wrote:
> On Thu, 2004-03-11 at 18:14, Kay Sievers wrote:
> > On Thu, 2004-03-11 at 16:06, David Zeuthen wrote:
> > > On Thu, 2004-03-11 at 15:30, Kay Sievers wrote:
> > Just make udevsend wait until the nodes are created (we already have a
> > patch for it from Chris) and execute udevsend as the first program with
> > /sbin/hotplug. All the following programs are sure that the nodes on
> > it's place and can query the node names with udevinfo. Easy, clean, nice
> > transparent and understandable.
> > 
> 
> Wearing a purist-hat, I would consider this a bad hack - so you want to
> hardcode the requirement that udevinfo needs to run before anything into
> whatever hotplug multiplexor is running? 

Why? If you don't need the node names don't wait for udevsend and don't
call udevinfo.

> What if I want to write a hotplug multiplexor that runs a number of
> programs in parallel in response to a hotplug event? What if I want to
> write another implementation of a device node manager to replace udev? 
> (not that I want to at, I really like udev, but I'm against setting
> requirements on how a hotplug multiplexor should work).

What do you think of?
There are no requirements. If your script rely on the dynamically
nodes,  you need to wait for udev anyway. If not, just go ahead.

> > udev is a device node manager, nothing more. I _strongly_ disagree on
> > making udev a arbitrary hotplug script engine. Please solve the problem
> > on it's source not on the first comfortable place :)
> 
> No. I'm simply asking that udev executes a program when it add/removes
> device nodes, that's all - calling this an arbritary hotplug script
> engine is simply not representative of what I ask for. I've said I'm
> even willing to write the patch myself :-)

I expect lot of lazy people to put their scripts in there, cause it's so
comfortable to live inside the serialized hotplug events.

Something like this:
"Nice, I can mount my USB-stick with udev.d/ right after udev has
created my partition node, cause the scsi.agent was too fast..."

So I still vote for not doing this.

thanks,
Kay



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id\x1470&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

  parent reply	other threads:[~2004-03-11 18:12 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-17 21:44 udev and DBUS Marco d'Itri
2004-02-26 17:00 ` Marco d'Itri
2004-02-28 14:13 ` David Zeuthen
2004-03-10 16:31 ` udev and dbus David Zeuthen
2004-03-10 17:52 ` Kay Sievers
2004-03-10 19:18 ` Greg KH
2004-03-10 19:56 ` Greg KH
2004-03-10 19:57 ` Marco d'Itri
2004-03-10 20:00 ` Marco d'Itri
2004-03-10 20:02 ` Greg KH
2004-03-10 22:25 ` Patrick Mansfield
2004-03-10 22:37 ` Kay Sievers
2004-03-10 22:48 ` Greg KH
2004-03-11  1:28 ` Greg KH
2004-03-11  2:35 ` Kay Sievers
2004-03-11  8:55 ` Martin Waitz
2004-03-11 14:30 ` Kay Sievers
2004-03-11 15:06 ` David Zeuthen
2004-03-11 17:14 ` Kay Sievers
2004-03-11 17:23 ` Kay Sievers
2004-03-11 17:30 ` David Zeuthen
2004-03-11 17:41 ` David Zeuthen
2004-03-11 17:44 ` Kay Sievers
2004-03-11 18:12 ` Kay Sievers [this message]
2004-03-11 18:22 ` David Zeuthen
2004-03-11 18:32 ` Greg KH
2004-03-11 18:35 ` Greg KH
2004-03-11 18:36 ` Greg KH
2004-03-11 18:37 ` Kay Sievers
2004-03-11 18:38 ` Kay Sievers
2004-03-11 18:40 ` Kay Sievers
2004-03-11 18:47 ` Greg KH
2004-03-11 18:56 ` Kay Sievers
2004-03-12  0:18 ` Greg KH
2004-03-12 11:37 ` David Zeuthen
2004-03-12 15:54 ` Kay Sievers
2004-03-12 16:40 ` Daniel Stekloff
2004-03-12 17:17 ` Marco d'Itri
2004-03-12 17:26 ` Marco d'Itri
2004-03-13 15:22 ` David Zeuthen
2004-03-13 18:29 ` Kay Sievers
2004-03-14 19:59 ` Olaf Hering
2004-03-14 20:06 ` Kay Sievers
2004-03-14 20:11 ` Olaf Hering

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=1079028775.1127.149.camel@pim \
    --to=kay.sievers@vrfy.org \
    --cc=linux-hotplug@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).