re: CVS commit: src/tests
> (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.
re: CVS commit: src/sys/kern
> 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/kernel
In article <20130219224428.5dd5717...@cvs.netbsd.org>,
Paul Goyette 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/tests/kernel
On Tue, Feb 19, 2013 at 02:45:43PM -0500, Julio Merino wrote: > On Tue, Feb 19, 2013 at 2:43 PM, Joerg Sonnenberger > 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
On Tue, Feb 19, 2013 at 2:43 PM, Joerg Sonnenberger 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
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
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
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
