From: Kay Sievers <kay.sievers@vrfy.org>
To: linux-hotplug@vger.kernel.org
Subject: Re: Test script for udevd binary, Request for Comments!
Date: Thu, 08 Apr 2004 20:49:34 +0000 [thread overview]
Message-ID: <20040408204934.GA31601@vrfy.org> (raw)
In-Reply-To: <3ACA40606221794F80A5670F0AF15F84037B9188@PDSMSX403.ccr.corp.intel.com>
On Thu, Apr 08, 2004 at 09:22:25AM -0700, Sabharwal, Atul wrote:
> Where is the timeout happening ?
The timeout happens if a sequence number is missing and udevd will
wait for the missing events until the timout happens and we skip the
missing sequences, you may look at 'man udevd' for a short description.
Kay
> On Wed, Apr 07, 2004 at 06:53:21PM +0800, Yin, Hu wrote:
> > Hi, All,
> >
> > I have written a test script for udevd binary. As you know there have
> been
> > some good test scripts for udev binary but we didn't write the
> corresponding
> > test scripts for the new udev's binaries since udev is split into
> several
> > binary program. Moreover, I think the work is necessary, especially
> for
> > udevd and udevsend binaries.
> >
> > Now I focus on the validation of udev as a Intel's intern student, so
> wrote
> > this test script for udevd and send it to all. I know this script is
> not
> > very good and enough for udevd's test but I believe we can do better
> with
> > the help from all of you. So please just take a look at this script
> and give
> > me some advises and suggestions in order that we can improve it
> together.
>
> The timout is 10 seconds now.
>
> It is not acceptable for a test like this, to work on the "real"
> $udev_root.
> It may render your system unusable!
>
> I prefer a test for udevsend/udevd only, not calling the real udev. You
> may
> change udevd to look on startup in the environment for the key UDEV_BIN
> and
> take this value instead of the real udev. Then you replace the real udev
> by
> a call to a small test program, which maybe writes a log file to be
> analyzed
> by your test script.
> This way you test the daemon only, not udev and udevd together and you
> are
> able to check if the logic for holding back events for the same device
> and
> execute different devices in parallel, works too.
>
> And a second time: Two events with the same sequence number are not a
> case we need to handle differently than a missing sequence number. A
> test for it is nice, but a timeout is the expected behavior.
>
> What do you think?
>
> 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
>
>
>
> -------------------------------------------------------
> 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
>
-------------------------------------------------------
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Ìk
_______________________________________________
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-04-08 20:49 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-07 10:53 Test script for udevd binary, Request for Comments! Yin, Hu
2004-04-08 14:16 ` Kay Sievers
2004-04-08 16:22 ` Sabharwal, Atul
2004-04-08 20:49 ` Kay Sievers [this message]
2004-04-09 10:45 ` Nick Yin
2004-04-09 20:52 ` Kay Sievers
2004-04-10 4:39 ` Nick Yin
2004-04-10 14:04 ` Kay Sievers
2004-04-10 14:48 ` Nick Yin
2004-04-13 10:34 ` Yin, Hu
2004-04-13 13:25 ` Kay Sievers
2004-04-13 13:51 ` Nick Yin
2004-04-14 3:11 ` Yin, Hu
2004-04-14 12:18 ` Kay Sievers
2004-04-14 15:24 ` Nick Yin
2004-04-14 15:33 ` Kay Sievers
2004-04-15 1:03 ` Yin, Hu
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=20040408204934.GA31601@vrfy.org \
--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 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.