Re: CVS commit: src
On 12 February 2012 10:06, Jukka Ruohonen wrote: > On Sun, Feb 12, 2012 at 10:53:56AM +0100, Martin Husemann wrote: >> > tests/sys/kern/t_module.c >> > ... >> and >> test/sys/kern/posix_spawn/* >> >> I don't mind moving it there, if there is consensus. We can clean other stuff >> later. I don't like mixing it with tons of unrelated tests in a common >> directory though. > > As said, please follow the libc-structure, as it is the current convention; > > libc/sys -> tests/lib/libc/sys > libc/gen -> tests/lib/libc/gen > > and also > > lib/librt -> tests/lib/librt > > even though majority of this stuff is implenented inside the kernel. Could I suggest a tests/README which documents the current convention (and notes the exceptions which should be cleaned up), so the next new person committing tests has guidance to follow?
Re: CVS commit: src
On Sun, Feb 12, 2012 at 10:53:56AM +0100, Martin Husemann wrote: > > tests/sys/kern/t_module.c > > ... > and > test/sys/kern/posix_spawn/* > > I don't mind moving it there, if there is consensus. We can clean other stuff > later. I don't like mixing it with tons of unrelated tests in a common > directory though. As said, please follow the libc-structure, as it is the current convention; libc/sys -> tests/lib/libc/sys libc/gen -> tests/lib/libc/gen and also lib/librt -> tests/lib/librt even though majority of this stuff is implenented inside the kernel. There is also a more philosophical argument; unit tests like this should not care what the implementation is or where it resides -- you are testing the POSIX interface, so the logical place is the "user visible frontend", not where it might be implemented. For comparable reasons, we put manual pages to the libc directory structure, not to sys/kern. - Jukka.
Re: CVS commit: src
On Sun, Feb 12, 2012 at 11:20:49AM +0200, Jukka Ruohonen wrote: > Yeah, that would get rid of the current: > > tests/kernel > tests/ipf > tests/dev > tests/modules > ... > > so we'd have like > > tests/sys/kern/t_module.c > ... and test/sys/kern/posix_spawn/* I don't mind moving it there, if there is consensus. We can clean other stuff later. I don't like mixing it with tons of unrelated tests in a common directory though. Martin
Re: CVS commit: src
On Sun, Feb 12, 2012 at 08:02:59PM +1100, matthew green wrote: > i don't see why tests/sys doesn't follow the consensus. > there's a src/sys afterall. (i don't get why 'rc' subdir > is in there, though.) Yeah, that would get rid of the current: tests/kernel tests/ipf tests/dev tests/modules ... so we'd have like tests/sys/kern/t_module.c ... All in all, a classical example of things that should've been discussed upfront, especially given the stone age rename support in CVS. - Jukka.
re: CVS commit: src
> > > Because of the consensus that /tests should mimic /src. The same note > > > applies to more or less all syscalls etc. Generally, the current > > > tests/kernel, tests/syscall, tests/utils et. cetera. will lead to a unholy > > > maintainability mess in the long-term. > > > > Yes, but then it should go to src/tests/sys/kern, or better into a > > subdirectory there. However, src/tests/sys seems to be something quite > > different. > > No. The tests/sys subdirectory is yet again another anomaly and should be > removed. i don't see why tests/sys doesn't follow the consensus. there's a src/sys afterall. (i don't get why 'rc' subdir is in there, though.) .mrg.
Re: CVS commit: src
On Sun, Feb 12, 2012 at 09:37:25AM +0100, Martin Husemann wrote: > On Sun, Feb 12, 2012 at 10:21:44AM +0200, Jukka Ruohonen wrote: > > Because of the consensus that /tests should mimic /src. The same note > > applies to more or less all syscalls etc. Generally, the current > > tests/kernel, tests/syscall, tests/utils et. cetera. will lead to a unholy > > maintainability mess in the long-term. > > Yes, but then it should go to src/tests/sys/kern, or better into a > subdirectory there. However, src/tests/sys seems to be something quite > different. No. The tests/sys subdirectory is yet again another anomaly and should be removed. Why not just follow the simple principle: use the directory structure you used for the libc parts. We already follow a comparable principle with the section 2 manual pages. I've tried to clean-up the current mess; it is already hard enough to locate the individual tests for maintenance. For instance, few times people have already added duplicate test files (instead of appending test cases), presumably because of the lack of structure. - Jukka.
Re: CVS commit: src
On Sun, Feb 12, 2012 at 10:21:44AM +0200, Jukka Ruohonen wrote: > Because of the consensus that /tests should mimic /src. The same note > applies to more or less all syscalls etc. Generally, the current > tests/kernel, tests/syscall, tests/utils et. cetera. will lead to a unholy > maintainability mess in the long-term. Yes, but then it should go to src/tests/sys/kern, or better into a subdirectory there. However, src/tests/sys seems to be something quite different. Another option would be src/tests/lib/libc/sys/posix_spawn. Or just leave it where it is now. Martin
Re: CVS commit: src
On Sun, Feb 12, 2012 at 09:10:11AM +0100, Martin Husemann wrote: > On Sun, Feb 12, 2012 at 08:21:47AM +0200, Jukka Ruohonen wrote: > > On Sat, Feb 11, 2012 at 11:31:25PM +, Martin Husemann wrote: > > > src/tests/kernel/posix_spawn: Makefile Makefile.inc h_fileactions.c > > > h_nonexec.sh h_spawn.c h_spawnattr.c t_fileactions.c t_spawn.c > > > t_spawnattr.c > > > > The tests should've gone to tests/lib/libc/gen... > > Why do you think so? They only test libc functionality in a very small > part. Because of the consensus that /tests should mimic /src. The same note applies to more or less all syscalls etc. Generally, the current tests/kernel, tests/syscall, tests/utils et. cetera. will lead to a unholy maintainability mess in the long-term. - Jukka.
Re: CVS commit: src
On Sun, Feb 12, 2012 at 08:21:47AM +0200, Jukka Ruohonen wrote: > On Sat, Feb 11, 2012 at 11:31:25PM +, Martin Husemann wrote: > > src/tests/kernel/posix_spawn: Makefile Makefile.inc h_fileactions.c > > h_nonexec.sh h_spawn.c h_spawnattr.c t_fileactions.c t_spawn.c > > t_spawnattr.c > > The tests should've gone to tests/lib/libc/gen... Why do you think so? They only test libc functionality in a very small part. Martin
