While there, it does not build for me:
/usr/src/tests/kernel/h_fexecve.c: In function 'main':
/usr/src/tests/kernel/h_fexecve.c:48:6: error: implicit declaration of
function 'fexecve'; did you mean 'execve'?
[-Werror=implicit-function-declaration]
if (fexecve(fd, args, NULL) == -1)
^~~
I have got no opinion, but merging them is good. Personally I prefer
src/libc/* path as fexecve(2) is a libc public symbol.
On 15.09.2019 20:06, Christos Zoulas wrote:
> The tests are a different. Should we keep them both, or try to merge them?
> I think that merging them is probably better. It is
The tests are a different. Should we keep them both, or try to merge them?
I think that merging them is probably better. It is also the case that perhaps
we need to get rid of the kernel tests directory and move them to the
respective bin and lib directories to avoid confusion?
christos
> On Sep
On 15.09.2019 18:53, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Sun Sep 15 16:53:58 UTC 2019
>
> Modified Files:
> src/tests/kernel: Makefile
> Added Files:
> src/tests/kernel: h_fexecve.c t_fexecve.sh
>
> Log Message:
> Add tests for fexecve(2
> Modified Files:
> src/tests/kernel: t_timeleft.c
>
> Log Message:
> add call error checks, requested by mrg@
thanks!
On Jan 14, 9:29am, m...@eterna.com.au (matthew green) wrote:
-- Subject: re: CVS commit: src/tests/kernel
| "Christos Zoulas" writes:
| > Module Name:src
| > Committed By: christos
| > Date: Sun Jan 13 15:36:57 UTC 2019
| >
| > Modified
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Sun Jan 13 15:36:57 UTC 2019
>
> Modified Files:
> src/tests/kernel: t_timeleft.c
>
> Log Message:
> Increase the timeout a bit, and make sure we join so that there is no
> race.
i notice both pthread_ki
On 07.12.2016 01:08, Christos Zoulas wrote:
> In article <0a6e53d7-4f6e-6e25-cd61-2342e1c4e...@gmx.com>,
> Kamil Rytarowski wrote:
>> -=-=-=-=-=-
>> -=-=-=-=-=-
>>
>> On 06.12.2016 19:59, Christos Zoulas wrote:
>>> Module Name:src
>>> Committed By: christos
>>> Date:
In article <0a6e53d7-4f6e-6e25-cd61-2342e1c4e...@gmx.com>,
Kamil Rytarowski wrote:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>On 06.12.2016 19:59, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Tue Dec 6 18:59:00 UTC 2016
>>
>> Modified Files:
>> src/
On 06.12.2016 19:59, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Tue Dec 6 18:59:00 UTC 2016
>
> Modified Files:
> src/tests/kernel: t_ptrace_wait.c
>
> Log Message:
> switch to using fork so we can see the child output.
>
atf_utils_fork() still wo
On Nov 26, 3:24am, n...@gmx.com (Kamil Rytarowski) wrote:
-- Subject: Re: CVS commit: src/tests/kernel
| PT_READ_D and PT_READ_I read single int according to documentation.
|
| In tests io_read_d* io_read_i* data blocks are printed with appropriate
| PRIxN.
|
| I cannot spot a mistake in the
On 25.11.2016 23:41, Christos Zoulas wrote:
> In article ,
> Christos Zoulas wrote:
>> In article <20161125200105.5dbb4f...@cvs.netbsd.org>,
>> Kamil Rytarowski wrote:
>>> -=-=-=-=-=-
>>>
>>> Module Name:src
>>> Committed By: kamil
>>> Date: Fri Nov 25 20:01:05 UTC 201
In article ,
Christos Zoulas wrote:
>In article <20161125200105.5dbb4f...@cvs.netbsd.org>,
>Kamil Rytarowski wrote:
>>-=-=-=-=-=-
>>
>>Module Name: src
>>Committed By: kamil
>>Date: Fri Nov 25 20:01:05 UTC 2016
>>
>>Modified Files:
>> src/tests/kernel: t_ptrace_wait.c
>>
>>Log Messa
In article <20161125200105.5dbb4f...@cvs.netbsd.org>,
Kamil Rytarowski wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: kamil
>Date: Fri Nov 25 20:01:05 UTC 2016
>
>Modified Files:
> src/tests/kernel: t_ptrace_wait.c
>
>Log Message:
>Fix several printf(3)-like functions usa
On 10.11.2016 03:44, matthew green wrote:
> it would actually be useful to have a testcase that ran iff
> root *and* securelevel >= 0 and tests it is unable to attach
> to pid 1.
>
> thanks.
>
>
> .mrg.
>
OK, I will have a look at it.
signature.asc
Description: OpenPGP digital signature
it would actually be useful to have a testcase that ran iff
root *and* securelevel >= 0 and tests it is unable to attach
to pid 1.
thanks.
.mrg.
On 10.11.2016 03:28, Paul Goyette wrote:
> On Thu, 10 Nov 2016, matthew green wrote:
>
also, root can't attach to pid1 if securelevel is >= 0.
>>>
>>> To adjust securelevel this test would need to be modified to run under
>>> rump ... We wouldn't want the test to manipulate securelevel of
On Thu, 10 Nov 2016, matthew green wrote:
also, root can't attach to pid1 if securelevel is >= 0.
To adjust securelevel this test would need to be modified to run under
rump ... We wouldn't want the test to manipulate securelevel of the
running system.
s/wouldn't want/*can't* by design have
> >> Log Message:
> >> Add new tests attach_pid0 and attach_pid1 to t_ptrace
> >>
> >> attach_pid0 asserts that it is not valid to attach PID 0 as it is a special
> >> kernel process.
> >>
> >> assert_pid1 asserts that non-root user cannot attach to PID 1 as it is the
> >> /dev/init process. This t
On Thu, 10 Nov 2016, matthew green wrote:
"Kamil Rytarowski" writes:
Module Name:src
Committed By: kamil
Date: Sun Nov 6 16:24:16 UTC 2016
Modified Files:
src/tests/kernel: t_ptrace.c
Log Message:
Add new tests attach_pid0 and attach_pid1 to t_ptrace
attach_pid0 asse
"Kamil Rytarowski" writes:
> Module Name: src
> Committed By: kamil
> Date: Sun Nov 6 16:24:16 UTC 2016
>
> Modified Files:
> src/tests/kernel: t_ptrace.c
>
> Log Message:
> Add new tests attach_pid0 and attach_pid1 to t_ptrace
>
> attach_pid0 asserts that it is not valid to atta
On 06.11.2016 18:26, Nicolas Joly wrote:
> On Sun, Nov 06, 2016 at 11:56:31PM +0700, Robert Elz wrote:
>> Date:Sun, 6 Nov 2016 16:24:16 +
>> From:"Kamil Rytarowski"
>> Message-ID: <20161106162416.95d77f...@cvs.netbsd.org>
>>
>> | assert_pid1 asserts that non-ro
On Sun, Nov 06, 2016 at 11:56:31PM +0700, Robert Elz wrote:
> Date:Sun, 6 Nov 2016 16:24:16 +
> From:"Kamil Rytarowski"
> Message-ID: <20161106162416.95d77f...@cvs.netbsd.org>
>
> | assert_pid1 asserts that non-root user cannot attach to PID 1 as it is the
> |
On 06.11.2016 17:56, Robert Elz wrote:
> Date:Sun, 6 Nov 2016 16:24:16 +
> From:"Kamil Rytarowski"
> Message-ID: <20161106162416.95d77f...@cvs.netbsd.org>
>
> | assert_pid1 asserts that non-root user cannot attach to PID 1 as it is the
> | /dev/init process.
Date:Sun, 6 Nov 2016 16:24:16 +
From:"Kamil Rytarowski"
Message-ID: <20161106162416.95d77f...@cvs.netbsd.org>
| assert_pid1 asserts that non-root user cannot attach to PID 1 as it is the
| /dev/init process. This tests is skipped if run as root.
There's no ne
On Nov 6, 1:48pm, n...@gmx.com (Kamil Rytarowski) wrote:
-- Subject: Re: CVS commit: src/tests/kernel
| My plan is to split t_ptrace into t_ptrace_wait, t_ptrace_waitpid etc. I
| will try to avoid duplication of the code and prepare something like the
| t_mutex and t_timedmutex pair.
|
| To
On 03.11.2016 18:08, Kamil Rytarowski wrote:
>
> For now I'm focusing on functional tests, which are equivalent to
> FreeBSD capabilities. This is why I will reschedule combination of
> wait(2) usage functions for later and move to on other ptrace(2) use-cases.
>
With recent reported issues I'm
On 03.11.2016 15:24, Christos Zoulas wrote:
> In article <19801.1478175...@andromeda.noi.kre.to>,
> Robert Elz wrote:
>>
>> Which is actually correct? (That is, which makes more sense, if it is
>> not actually specified somewhere.)
>>
>> Please make the tests test correct behaviour, not just wh
In article <19801.1478175...@andromeda.noi.kre.to>,
Robert Elz wrote:
>
>Which is actually correct? (That is, which makes more sense, if it is
>not actually specified somewhere.)
>
>Please make the tests test correct behaviour, not just what NetBSD happens
>to do today. If NetBSD is doing som
Date:Thu, 3 Nov 2016 11:20:45 +
From:"Kamil Rytarowski"
Message-ID: <20161103112045.a48aaf...@cvs.netbsd.org>
| This test verifies calling raise(2) with the SIGCONT argument in the child.
| The parent is notified with it and asserts that WIFCONTINUED() and
|
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:
>
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 differen
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 c
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 t
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.
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 barri
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?:)
Index: t_lockf.c
===
On Tue, Feb 19, 2013 at 12:54:48AM +, Paul Goyette wrote:
> Module Name: src
> Committed By: pgoyette
> Date: Tue Feb 19 00:54:48 UTC 2013
>
> Modified Files:
> src/tests/kernel: t_lockf.c
>
> Log Message:
> Wait a little bit after fork()ing the lockers to give them a chance to
On 5/31/11 7:06 PM, Jukka Ruohonen wrote:
On Sat, May 28, 2011 at 04:53:21PM +0100, Julio Merino wrote:
One thing is reorganizing the tests to match the tree structure, but the
other is to move the tests right next to the source
I don't quite understand the latter part. Why is this a bad thing
On Sat, May 28, 2011 at 04:53:21PM +0100, Julio Merino wrote:
> One thing is reorganizing the tests to match the tree structure, but the
> other is to move the tests right next to the source
I don't quite understand the latter part. Why is this a bad thing?
I always thought that having a single u
On Sun, May 29, 2011 at 12:53 AM, Julio Merino wrote:
> On 5/28/11 4:37 PM, Christos Zoulas wrote:
>>
>> Module Name: src
>> Committed By: christos
>> Date: Sat May 28 15:37:11 UTC 2011
>>
>> Modified Files:
>> src/tests/kernel: t_pollts.c
>>
>> Log Message:
>> PR/44896 has b
On 5/28/11 4:37 PM, Christos Zoulas wrote:
Module Name:src
Committed By: christos
Date: Sat May 28 15:37:11 UTC 2011
Modified Files:
src/tests/kernel: t_pollts.c
Log Message:
PR/44896 has been fixed.
BTW: We've created a mess here again with the directory structure of th
42 matches
Mail list logo
