Re: CVS commit: src/tests/kernel

2013-02-19 Thread Joerg Sonnenberger 
On Mon, Feb 18, 2013 at 07:24:39PM -0800, Paul Goyette wrote:
 On Tue, 19 Feb 2013, Joerg Sonnenberger wrote:
 
 Wait a little bit after fork()ing the lockers to give them a chance to
 get started before trying to ptrace(ATTACH).
 
 What about using a pipe to make this an explicit barrier?
 
 
 You mean something like this?:)

Almost. Don't use printf after fork(), otherwise fine.

Joerg

Re: CVS commit: src/tests/kernel

2013-02-19 Thread Paul Goyette 
Most of the printf's were already there before this round of updates, 
and there's enough differentiation in them to figure out which process 
is responsible.  In any case, the printf's aren't critical to the test 
(until you need to debug it!).


So for now, I'd rather just leave them all alone.  The test is now 
working correctly.


Thanks for the suggestion - definitely much better than wait and hope 
approach!  :)



On Tue, 19 Feb 2013, Joerg Sonnenberger wrote:


On Mon, Feb 18, 2013 at 07:24:39PM -0800, Paul Goyette wrote:

On Tue, 19 Feb 2013, Joerg Sonnenberger wrote:


Wait a little bit after fork()ing the lockers to give them a chance to
get started before trying to ptrace(ATTACH).


What about using a pipe to make this an explicit barrier?



You mean something like this?:)


Almost. Don't use printf after fork(), otherwise fine.

Joerg

!DSPAM:5123d2da267581420614406!




-
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:   |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |  | pgoyette at netbsd.org  |
-

Re: CVS commit: src/tests/kernel

2013-02-19 Thread Joerg Sonnenberger 
On Tue, Feb 19, 2013 at 11:40:22AM -0800, Paul Goyette wrote:
 Most of the printf's were already there before this round of
 updates, and there's enough differentiation in them to figure out
 which process is responsible.  In any case, the printf's aren't
 critical to the test (until you need to debug it!).

I am talking about the *new* printf in the child process.
That should just be a plain write to STDERR_FILENO, it doesn't even have
to include any more error details.

Joerg

Re: CVS commit: src/tests/kernel

2013-02-19 Thread Julio Merino 
On Tue, Feb 19, 2013 at 2:43 PM, Joerg Sonnenberger
jo...@britannica.bec.de wrote:
 On Tue, Feb 19, 2013 at 11:40:22AM -0800, Paul Goyette wrote:
 Most of the printf's were already there before this round of
 updates, and there's enough differentiation in them to figure out
 which process is responsible.  In any case, the printf's aren't
 critical to the test (until you need to debug it!).

 I am talking about the *new* printf in the child process.
 That should just be a plain write to STDERR_FILENO, it doesn't even have
 to include any more error details.

This is pure curiosity: isn't a fflush(stderr) right before the fork()
enough to make printf() safe in the child? If not, why not?

-- 
Julio Merino / @jmmv

Re: CVS commit: src/tests/kernel

2013-02-19 Thread Joerg Sonnenberger 
On Tue, Feb 19, 2013 at 02:45:43PM -0500, Julio Merino wrote:
 On Tue, Feb 19, 2013 at 2:43 PM, Joerg Sonnenberger
 jo...@britannica.bec.de wrote:
  On Tue, Feb 19, 2013 at 11:40:22AM -0800, Paul Goyette wrote:
  Most of the printf's were already there before this round of
  updates, and there's enough differentiation in them to figure out
  which process is responsible.  In any case, the printf's aren't
  critical to the test (until you need to debug it!).
 
  I am talking about the *new* printf in the child process.
  That should just be a plain write to STDERR_FILENO, it doesn't even have
  to include any more error details.
 
 This is pure curiosity: isn't a fflush(stderr) right before the fork()
 enough to make printf() safe in the child? If not, why not?

Depends on the buffering mode it is in. Basically, I consider it a bad
style that should be avoided.

Joerg

Re: CVS commit: src/tests/kernel

2013-02-19 Thread Christos Zoulas 
In article 20130219224428.5dd5717...@cvs.netbsd.org,
Paul Goyette source-changes-d@NetBSD.org wrote:
-=-=-=-=-=-

+  const char *pipe_errmsg = child: pipe write failed\n;
 
   (void)unlink(lockfile);
 
@@ -145,8 +146,8 @@ ATF_TC_BODY(randlock, tc)
   switch (pid[i]) {
   case 0:
   if (write(pipe_fd[1], pipe_out, 1) != 1)
-  printf(write_pipe(%i): %s, i,
-  strerror(errno));
+  write(STDERR_FILENO, pipe_errmsg,
+  __arraycount(pipe_errmsg));

foo is a pointer so this will print the first sizeof(char *) characters.
Even if you correct it to be char foo[] you need arraycount() - 1 so you
don't print the NUL.

christos

re: CVS commit: src/sys/kern

2013-02-19 Thread matthew green 

 Module Name:  src
 Committed By: martin
 Date: Tue Feb 19 11:20:17 UTC 2013
 
 Modified Files:
   src/sys/kern: subr_xcall.c
 
 Log Message:
 Oops, accidently did not commit this part of pooka's change.

please update the commit log to reference the original commit,
rather than the above which will be much less obvious to someone
looking in a few years time.

thanks,


.mrg.

re: CVS commit: src/tests

2013-02-19 Thread matthew green 

 (Due to the way our directory creation and file lists work, I'm not
 sure it's possible to just not install the empty directory.  But
 that'd be an alternative to this.)

see eg, src/etc/mtree/NetBSD.dist.*.


.mrg.