All of lore.kernel.org
 help / color / mirror / Atom feed
From: sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org
To: Subrata Modak
	<subrata-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Cc: Containers <containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org>,
	ltp-list-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
	Serge Hallyn
	<serue-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>,
	Alan Cox <alan-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org>,
	hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org
Subject: Re: ptem01 LTP failure in ttydev-0909
Date: Sat, 1 Nov 2008 13:33:03 -0700	[thread overview]
Message-ID: <20081101203303.GG24472@us.ibm.com> (raw)
In-Reply-To: <1222259777.5395.7.camel-NRFfyExJdYpgXGGE5LP+UZlqa2bBAFbm0E9HWUfgJXw@public.gmane.org>


Sorry, this was buried in my inbox...

Subrata Modak [subrata-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org] wrote:
| Hi Sukadev,
| 
| On Thu, 2008-09-18 at 21:14 -0700, sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org wrote:
| > Alan Cox [alan-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org] wrote:
| > | > The test changes the window size using the slave-fd and expects that
| > | > it won't affect the window-size on master-fd. With this change, we
| > | > return the slave's window size and test fails.
| > | 
| > | I've no idea why anyone would have thought the existing behaviour was
| > | correct. The pty/tty pair code tries to share the size and other
| > | information at all times and the old test was I think verifying a bug
| > | existed.
| > | 
| > | Unless anyone can cite anything to show otherwise anyway ?
| > 
| > Subrata 
| > 
| > We are referring to the last window size check in test2() of
| > testcases/kernel/pty/ptem01.c. This check will cause the test
| > to fail when some of the planned ttydev changes are merged.
| > 
| > Would you happen to know if the check is really required or if
| > it should be dropped ?
| 
|  I would want the test to remain there, but introduce some checkings
| before running the test. As test2() is valid under present
| circumstances, we should retain it as people will keep using LTP on
| lower kernels.

Just to be clear, the entire test2() is not broken. Only the last part
(see patch below) Other parts of test2() should be fine even with
new changes.

| 
| Having said that, i would like to come with a solution where test2() of
| testcases/kernel/pty/ptem01.c is not run after the planned ttydev
| changes are merged. Something compile/run time checking to either not to
| build that part of code and run it. Can we do something like that by
| checking some glibc/kernel exported definitions ?

Other than the kernel version when the changes are merged, I am not sure
there is a way. Besides, it is not clear which assertion that part of
test2() is testing and if it is even needed for older kernels.

Here is the part of test2() I am referring to:

---
 testcases/kernel/pty/ptem01.c |   12 ------------
 1 file changed, 12 deletions(-)

Index: ltp-full-20071031/testcases/kernel/pty/ptem01.c
===================================================================
--- ltp-full-20071031.orig/testcases/kernel/pty/ptem01.c        2008-11-01 13:30:42.977954127 -0700
+++ ltp-full-20071031/testcases/kernel/pty/ptem01.c     2008-11-01 13:31:41.439427078 -0700
@@ -238,18 +238,6 @@ test2(void)
                tst_exit();
        }

-       if (ioctl(masterfd, TIOCGWINSZ, &wsz) != 0) {
-               tst_resm(TFAIL,"TIOCGWINSZ");
-               tst_exit();
-       }
-
-       if (wsz.ws_row == wsz2.ws_row || wsz.ws_col == wsz2.ws_col ||
-           wsz.ws_xpixel == wsz2.ws_xpixel ||
-           wsz.ws_ypixel == wsz2.ws_ypixel) {
-               tst_resm(TFAIL, "unexpected window size returned");
-               tst_exit();
-       }
-
        if (close(slavefd) != 0) {
                tst_resm(TBROK,"close");
                tst_exit();

  parent reply	other threads:[~2008-11-01 20:33 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-11 20:11 ptem01 LTP failure in ttydev-0909 sukadev-r/Jw6+rmf7HQT0dZR+AlfA
     [not found] ` <20080911201159.GA17071-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2008-09-16 14:48   ` Alan Cox
     [not found]     ` <20080916154848.49337bf0-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org>
2008-09-19  4:14       ` sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
     [not found]         ` <20080919041408.GA31412-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2008-09-24 12:36           ` Subrata Modak
     [not found]             ` <1222259777.5395.7.camel-NRFfyExJdYpgXGGE5LP+UZlqa2bBAFbm0E9HWUfgJXw@public.gmane.org>
2008-11-01 20:33               ` sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8 [this message]
     [not found]                 ` <20081101203303.GG24472-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2008-11-03  7:26                   ` Subrata Modak

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=20081101203303.GG24472@us.ibm.com \
    --to=sukadev-23vcf4htsmix0ybbhkvfkdbpr1lh4cv8@public.gmane.org \
    --cc=alan-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org \
    --cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
    --cc=hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org \
    --cc=ltp-list-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    --cc=serue-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \
    --cc=subrata-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.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.