From: Olaf Hering <olh@suse.de>
To: linux-hotplug@vger.kernel.org
Subject: Re: [RFC] reliability and scalability
Date: Sat, 07 Feb 2004 20:20:06 +0000 [thread overview]
Message-ID: <20040207202006.GA28699@suse.de> (raw)
In-Reply-To: <40249B59.7080805@sympatico.ca>
On Sat, Feb 07, Greg KH wrote:
> On Sat, Feb 07, 2004 at 09:57:58AM +0100, Olaf Hering wrote:
> > On Sat, Feb 07, Chris Friesen wrote:
> >
> > > Comments, anyone?
> >
> > Better get rid of udevd and keep track of the latest add and remove
> > SEQNUMs in the database. unlink the devnodes and symlinks before
> > creating new ones during add events.
>
> And how would you re-order events in this situation?
What do you mean with reorder? Maybe I miss the point.
I assume the database has some locking to serialize writes (maybe even
reads).
- If an add event arrives, check if a remove event was recoreded.
If the remove event had a higher number than this add event, record this
add event as seen if no newer add event was seen, then exit.
If no remove and no newer add event was seen, unlink the node and
symlinks and recreate them. Record the current number as 'add'.
- If a remove event arrives, check if an add event was recorded.
If the add event had a higher number, record this remove event if no
newer remove event was seen, then exit.
Maybe something like this:
switch(action)
case add:
if (last.add > seqnum)
exit
if (last.remove > seqnum)
exit
last.add = seqnum
unlink (node)
mknod (node)
if (symlink) {
unlink (symlink)
ln (node, symlink)
}
exit
case remove:
if (last.add > seqnum)
exit
if (last.remove > seqnum)
exit
last.remove = seqnum
unlink (node)
if (symlink)
unlink (symlink)
exit
> No, udevd is needed.
I'm not convinced.
--
USB is for mice, FireWire is for men!
sUse lINUX ag, n√úRNBERG
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
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
next prev parent reply other threads:[~2004-02-07 20:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-07 8:01 [RFC] reliability and scalability Chris Friesen
2004-02-07 8:57 ` Olaf Hering
2004-02-07 9:49 ` Kay Sievers
2004-02-07 19:30 ` Greg KH
2004-02-07 19:31 ` Greg KH
2004-02-07 20:20 ` Olaf Hering [this message]
2004-02-09 3:59 ` Kay Sievers
2004-02-21 1:01 ` 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=20040207202006.GA28699@suse.de \
--to=olh@suse.de \
--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).