linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Rusty Lynch" <rusty@linux.co.intel.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: Hotplug Test Cases or Test Procedures
Date: Wed, 20 Nov 2002 17:30:39 +0000	[thread overview]
Message-ID: <marc-linux-hotplug-103781375618332@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-103775851104322@msgid-missing>

> Hi Rusty,
>
> What would you want the testcases or procedures to cover?  Are there
> tools, like 'cardctl eject' for cardbus/pcmcia, that interact with
> hotplug events in testable ways?  Particular drivers/hardware to test,
> maybe with setup scripts, or just certain core functionality?

We are just starting to scope this work out, so we don't know what
it will entail.  Initially we need to validate the operation of a couple
of cPCI systems ranging from basic functionality of the zt5550 driver
to system wide testing to verify once a given peripheral board is inserted,
all of the hotplug actions (like loading a driver) happen.  Eventually
there are other bladed architectures with hotplug capibilities people
are dreaming up that my group will need to help implement and test on
Linux.

I'm sure a lot of these test will be very specific a given setup (i.e. a
given
platform hotpluging a specific device), but at the very least it would be
nice
to provide a common way for people to upload other test procedures.

This ping is really my attempt at getting my group to work effectivly in
open source.  It is just too easy to go off and implement something
behind close doors only to find out you did it in a way that is not very
useful to the rest of the world.

>
> I don't know of any particular tests, but it'd be good to have some!
>
> It's easy enough to handle the "do modules X, Y, and Z load" parts,
> maybe even use a 'cardctl' analogue to simulate card insert/eject,
> and that part is driver-independent.  Stuff like setup scripts is
> harder to characterize, as well as driver-specific (except for the
> essentials like "did the script get run").
>
>
> It's not the same, but there is some info about debugging at the sf.net
> site (http://linux-hotplug.sourceforge.net/?selectedÞbug) which talks
> about applying one test technique when debugging ... it could easily get
> used in regression testing:
>
>   - save events
>   - play back later
>   - do they produce the intended result?
>
> I suspect a "save the events" routine should be part of the standard
> hotplug toolset, it'd have more uses than just debug, test, or logging.
>

Cool.  Thanks for the pointer.

>
> >>>Would this be something people would like to see in the hotplug CVS
> >>>repository?
>
> If it's really addressing the ways that user mode tools are
> alerted through /sbin/hotplug and /etc/hotplug/* support,
> I'd hope so!  Certainly everything that's shared with the
> other hotpluggable pci busses should be there, and I agree
> with you that
>
>
> >>..   Or we can just put it up on the web site.
> >
> >
> > Writing the procedures as html and making them accessable via the web
site
> > sounds like a good way to start.
>
> Yes.  Some would need to stay that way (where people need to do
> things like swap cards around), no matter how much can be automated.
>
> Are you volunteering to maintain those pages?
>

Yeap.  I can do that.  Actually I will be pulling in Guomin to work on this.
Guomin is just starting to get familiar with hotplug and pci hotplug, so
there will be some ramp up time.

>
> >>>Maybe I could approach the LTP?
> >>
> >>Traditionally they have only wanted tests that they can automate, and
> >>unfortunately, pci hotplug tests (and most driver tests) can't be
> >>automated very easily.  But it can't hurt to try asking them :)
> >
> >
> > I'll ping the LTP people to see if they are interested, but that
shouldn't
> > slow us down any.
>
> See above.  Some kinds of testing _can_ be automated without
> needing industrial robotics!

BTW, I talked with Stephanie Glass of the LTP project, and she believes
that there is a place we can put manual test procedures.  There test will
just not be part of the "run all" test cases.

I'm thinking adding test to LTP could be a long term goal, but we should
know more after something materializes.

>
> - Dave
>
>



-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing 
your web site with SSL, click here to get a FREE TRIAL of a Thawte 
Server Certificate: http://www.gothawte.com/rd524.html
_______________________________________________
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:[~2002-11-20 17:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-20  2:10 Hotplug Test Cases or Test Procedures Rusty Lynch
2002-11-20  2:47 ` Greg KH
2002-11-20  5:01 ` Rusty Lynch
2002-11-20  8:33 ` David Brownell
2002-11-20 17:30 ` Rusty Lynch [this message]

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=marc-linux-hotplug-103781375618332@msgid-missing \
    --to=rusty@linux.co.intel.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).