From: Bill Nottingham <notting@redhat.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: triggering udev rules based on the state of udevd
Date: Wed, 02 Jul 2008 16:26:49 +0000 [thread overview]
Message-ID: <20080702162649.GA24987@nostromo.devel.redhat.com> (raw)
In-Reply-To: <20080702151527.GA22892@nostromo.devel.redhat.com>
Kay Sievers (kay.sievers@vrfy.org) said:
> > There doesn't seem to be a good happy medium that allows for degraded assembly
> > when needed, but normal assembly in most cases. One potential way to do this
> > would be to queue events such as these RAID-handling events as 'idle', or
> > 'end of queue', such that they are always run at the end of queue after other
> > events have run. Is that sort of thing possible?
>
> What would be a "queue"? How would you define one?
The event queue... basically just a push an event to 'last'.
> Can't you run a "all I need is there" - check with every matching
> device, and make sure, you serialize/lock things properly, and only
> the last device/event would have all needed requirements and trigger
> the action, all earlier would just need to give up. The s390 stuff
> does things like that with the "collect" extra, Ubuntu has a
> "watershed" extra, which may do something like you need.
watershed just locks to avoid running multiple instances of the same
base command; it doesn't actually solve this. Moreover, just saying
'only the last device/event' isn't really proper - how do you tell what
is 'last' in the event of a degraded raid array?
Bill
next prev parent reply other threads:[~2008-07-02 16:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-02 15:15 triggering udev rules based on the state of udevd Bill Nottingham
2008-07-02 16:13 ` Kay Sievers
2008-07-02 16:26 ` Bill Nottingham [this message]
2008-07-02 16:32 ` Kay Sievers
2008-07-02 16:34 ` Bill Nottingham
2008-07-02 16:44 ` Bryan Kadzban
2008-07-02 16:45 ` Bill Nottingham
2008-07-02 22:12 ` Bryan Kadzban
2008-07-02 22:35 ` Hai Zaar
2008-07-03 13:09 ` Bill Nottingham
2008-07-03 16:29 ` Scott James Remnant
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=20080702162649.GA24987@nostromo.devel.redhat.com \
--to=notting@redhat.com \
--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).