Re: CVS import: src/external/bsd/kyua-cli/dist
On Sat, Oct 19, 2013 at 7:32 AM, Marc Balmer m...@msys.ch wrote: Am 19.10.13 01:40, schrieb Julio Merino: Module Name: src Committed By: jmmv Date: Fri Oct 18 23:40:48 UTC 2013 Update of /cvsroot/src/external/bsd/kyua-cli/dist In directory ivanova.netbsd.org:/tmp/cvs-serv22893 Log Message: Update kyua-cli to 0.7: The major reason for this update is to support the just-imported lutok-0.3 and, in turn, support the eventual update of the in-tree lua to 5.2. Changes: [...] * Switched to use Lutok 0.3 to gain compatibility with Lua 5.2. So your work would be safe and continue to build/work when Lua gets updated to 5.2? Correct! -- Julio Merino / @jmmv
Re: CVS commit: src
On Fri, Mar 1, 2013 at 1:26 PM, Joerg Sonnenberger jo...@netbsd.org wrote: Module Name:src Committed By: joerg Date: Fri Mar 1 18:26:12 UTC 2013 Modified Files: Log Message: Retire OSI network stack. OK core@ Not sure if this is related, but this is the only recent commit I see mentioning iso_var.h: /home/jmmv/os/netbsd/amd64/tools/bin/x86_64--netbsd-gcc -O2 -g -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-sign-compare -Wno-traditional -Wa,--fatal-warnings -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wno-unused-parameter -Wno-sign-compare -Wold-style-definition -Wsign-compare -Wformat=2 -Wno-format-zero-length -Werror --sysroot=/home/jmmv/os/netbsd/amd64/destdir -I/home/jmmv/os/netbsd/src/usr.bin/ktrace -I/home/jmmv/os/netbsd/src/sys -ckdump-ioctl.c In file included from kdump-ioctl.c:85:0: /home/jmmv/os/netbsd/amd64/destdir/usr/include/netiso/iso_snpac.h:67:18: error: field 'sr_isoa' has incomplete type In file included from kdump-ioctl.c:86:0: /home/jmmv/os/netbsd/amd64/destdir/usr/include/netiso/iso_var.h:77:22: error: field 'ia_addr' has incomplete type /home/jmmv/os/netbsd/amd64/destdir/usr/include/netiso/iso_var.h:78:22: error: field 'ia_dstaddr' has incomplete type /home/jmmv/os/netbsd/amd64/destdir/usr/include/netiso/iso_var.h:80:22: error: field 'ia_sockmask' has incomplete type /home/jmmv/os/netbsd/amd64/destdir/usr/include/netiso/iso_var.h:86:22: error: field 'ifra_addr' has incomplete type /home/jmmv/os/netbsd/amd64/destdir/usr/include/netiso/iso_var.h:87:22: error: field 'ifra_dstaddr' has incomplete type /home/jmmv/os/netbsd/amd64/destdir/usr/include/netiso/iso_var.h:88:22: error: field 'ifra_mask' has incomplete type /home/jmmv/os/netbsd/amd64/destdir/usr/include/netiso/iso_var.h:94:22: error: field 'ifr_Addr' has incomplete type -- Julio Merino / @jmmv
Re: CVS commit: src/external/bsd/kyua-atf-compat/dist
On Feb 25, 2013, at 13:54, David Holland dholland-sourcechan...@netbsd.org wrote: On Mon, Feb 25, 2013 at 06:49:51PM +, Julio Merino wrote: Log Message: Cherry-pick upstream change d0daf9983f5a0e635f1127dbc827aa114daa90d8: Fix broken variable parsing with NetBSD's /bin/sh Quote the expansion of a $() command that was not properly surrounded by quotes so that this runs properly with NetBSD's /bin/sh. In what way was it broken? (And where's the PR?) FTR: bin/47597
Re: CVS commit: src/external/bsd/kyua-atf-compat/dist
On Feb 25, 2013, at 15:40, Valeriy E. Ushakov u...@stderr.spb.ru wrote: On Mon, Feb 25, 2013 at 18:49:51 +, Julio Merino wrote: Module Name: src Committed By:jmmv Date:Mon Feb 25 18:49:51 UTC 2013 Modified Files: src/external/bsd/kyua-atf-compat/dist: atf-run.sh Log Message: Cherry-pick upstream change d0daf9983f5a0e635f1127dbc827aa114daa90d8: Fix broken variable parsing with NetBSD's /bin/sh Quote the expansion of a $() command that was not properly surrounded by quotes so that this runs properly with NetBSD's /bin/sh. grep|sed pipeline is ok on a command line where one is lazy, in a script it should be just sed :) Heh, very true. I'll try to play with this a bit later. Your $ws doesn't do what you expect it to do. Try your command on a line that actually has tabs. This is because backslash has no special meaning inside [], so your \t is not a tab, but either a backslash or a letter 't'. Thanks; this should be fixed now.
Re: CVS commit: src/external/bsd/kyua-atf-compat/dist
On Feb 25, 2013, at 14:01, Paul Goyette p...@whooppee.com wrote: On Mon, 25 Feb 2013, David Holland wrote: On Mon, Feb 25, 2013 at 06:49:51PM +, Julio Merino wrote: Log Message: Cherry-pick upstream change d0daf9983f5a0e635f1127dbc827aa114daa90d8: Fix broken variable parsing with NetBSD's /bin/sh Quote the expansion of a $() command that was not properly surrounded by quotes so that this runs properly with NetBSD's /bin/sh. In what way was it broken? (And where's the PR?) And when do we get a regression test case to detect it? Whenever we decide what the behavior should be! See the discussion that the PR started.
Re: CVS commit: src/external/bsd/kyua-atf-compat/dist
On Mon, Feb 25, 2013 at 1:54 PM, David Holland dholland-sourcechan...@netbsd.org wrote: On Mon, Feb 25, 2013 at 06:49:51PM +, Julio Merino wrote: Log Message: Cherry-pick upstream change d0daf9983f5a0e635f1127dbc827aa114daa90d8: Fix broken variable parsing with NetBSD's /bin/sh Quote the expansion of a $() command that was not properly surrounded by quotes so that this runs properly with NetBSD's /bin/sh. In what way was it broken? (And where's the PR?) I was assuming my code was broken, not sh. But I can file a PR with the observed difference between sh and bash. -- Julio Merino / @jmmv
Re: CVS commit: src/external/bsd
On Sat, Feb 23, 2013 at 9:18 AM, Julio Merino j...@netbsd.org wrote: Module Name:src Committed By: jmmv Date: Sat Feb 23 14:18:52 UTC 2013 Modified Files: src/external/bsd: Makefile Log Message: Makefile Fixed in the repository to read: Descend into kyua-cli when MKKYUA!=no. -- Julio Merino / @jmmv
Re: CVS commit: src/tests/kernel
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/regress/lib/libc/cdb
On Sat, Jul 21, 2012 at 7:12 PM, Mindaugas Rasiukevicius rm...@netbsd.org wrote: Jukka Ruohonen jruoho...@iki.fi wrote: Module Name:src Committed By: rmind Date: Sat Jul 21 22:22:55 UTC 2012 Added Files: src/regress/lib/libc/cdb: cdb_test.c Log Message: Add a simple test for cdb(5). Is there a particular reason why you do not use ATF but keep adding your custom test programs?? I recall some kind of resolution about this... (And IMO, even if you dislike ATF, you can not dislike the infrastructure.) Unfortunately, ATF is problematic and inconvenient to use for me. I can share my thoughts on this, if there is an interest. Please do. Ignoring the problem is not going to fix it. (Feel free to reply privately or email the atf-devel list only if you do not want to share at large for whatever reason.) Feel free to convert this to ATF. As for resolution - if you insist, I can stop adding the tests. Have you gone over http://wiki.netbsd.org/tutorials/atf/ ? (I guess you have, but just in case.) -- Julio Merino / @jmmv
Re: CVS commit: src/external/bsd/atf/lib/libatf-c++
On Thu, Jul 12, 2012 at 12:15 PM, Christos Zoulas chris...@netbsd.orgwrote: Module Name:src Committed By: christos Date: Thu Jul 12 16:15:40 UTC 2012 Modified Files: src/external/bsd/atf/lib/libatf-c++: Makefile Log Message: Properly include dependent library, unbreaks objdir build. Does bsd.test.mk need a similar change? It's also using DPADD.
Re: CVS commit: src/sbin/ifconfig
On 3/18/12 1:53 AM, Jukka Ruohonen wrote: On Fri, Mar 16, 2012 at 10:25:08PM -0400, Christos Zoulas wrote: Module Name:src Committed By: christos Date: Sat Mar 17 02:25:08 UTC 2012 Modified Files: src/sbin/ifconfig: af_inetany.c Log Message: PR/43141: Tobias Nygren: Print an error on unknown interfaces. Now this is trival and it is fixed. But I guess there is a bug here in ATF. The test only checks that the exit code is not zero: atf_check -s not-exit:0 ifconfig nonexistent0 1.2.3.4/24 But why is stderr being involved? If you really want to ignore stderr in the test, pass -e ignore to atf_check. The default is -o empty -e empty. Now, the question is: do you really want to ignore the message, or do you want to validate that the appropriate error message is printed? If the later (which should be the preferred way), -e inline:'foo bar\n' or -e match:'foo bar' or -e file:experr (with experr being pre-populated with the expected message) will do the job.
Re: CVS commit: src
On 2/17/12 5:43 PM, Matt Thomas wrote: On Feb 17, 2012, at 2:36 PM, Julio Merino wrote: Module Name:src Committed By: jmmv Date: Fri Feb 17 22:36:50 UTC 2012 Modified Files: src/distrib/sets/lists/tests: module.mi src/tests/modules: Makefile Added Files: src/tests/modules: t_abi_uvm.sh src/tests/modules/k_uvm: Makefile k_uvm.c Log Message: Add a test to ensure that PAGE_SIZE is available in kernel modules. This test reproduces the error condition in PR port-macppc/46041 and therefore it is an xfail in this particular platform. I explicitly made PAGE_SIZE unavailable for powerpc. This was part of having one consistent view for OEA,BOOKE,IBM4XX all which use different page size. So you can't rely on PAGE_SIZE. So the modules are broken on purpose?
Re: CVS commit: src
On 2/17/12 5:45 PM, Matt Thomas wrote: On Feb 17, 2012, at 2:43 PM, Julio Merino wrote: On 2/17/12 5:43 PM, Matt Thomas wrote: On Feb 17, 2012, at 2:36 PM, Julio Merino wrote: Module Name:src Committed By: jmmv Date: Fri Feb 17 22:36:50 UTC 2012 Modified Files: src/distrib/sets/lists/tests: module.mi src/tests/modules: Makefile Added Files: src/tests/modules: t_abi_uvm.sh src/tests/modules/k_uvm: Makefile k_uvm.c Log Message: Add a test to ensure that PAGE_SIZE is available in kernel modules. This test reproduces the error condition in PR port-macppc/46041 and therefore it is an xfail in this particular platform. I explicitly made PAGE_SIZE unavailable for powerpc. This was part of having one consistent view for OEA,BOOKE,IBM4XX all which use different page size. So you can't rely on PAGE_SIZE. So the modules are broken on purpose? Yes. Interesting. If that's the case, shouldn't we break PAGE_SIZE for all platforms and keep things consistent? The modules that are broken (see the referenced PR for a list) fail due to a missing uvmexp_pagesize symbol (*not* PAGE_SIZE itself), which I assumed was there to prevent depending on the PAGE_SIZE compile-time constant. I understand this information not being statically-available because of variable-page sizes in these platforms.
Re: CVS commit: src
On 2/17/12 5:58 PM, Matt Thomas wrote: On Feb 17, 2012, at 2:54 PM, Julio Merino wrote: On 2/17/12 5:45 PM, Matt Thomas wrote: On Feb 17, 2012, at 2:43 PM, Julio Merino wrote: So the modules are broken on purpose? Yes. Interesting. If that's the case, shouldn't we break PAGE_SIZE for all platforms and keep things consistent? For those with variable page sizes (like powerpc or mips), yes. I was asking about *all* platforms regardless of whether they have static or variable page sizes. Keeping this inconsistent seems like a very easy way of writing non-portable code... The modules that are broken (see the referenced PR for a list) fail due to a missing uvmexp_pagesize symbol (*not* PAGE_SIZE itself), which I assumed was there to prevent depending on the PAGE_SIZE compile-time constant. I understand this information not being statically-available because of variable-page sizes in these platforms. properly should use uvmexp.pagesize instead. Aha, I see. Does it make sense to keep the test after renaming PAGE_SIZE to uvmexp.pagesize? It's a public symbol after all and we really should have tests for these, I think. Do we need to go over the broken modules one by one and replace PAGE_SIZE with uvmexp.pagesize? (I'm expecting this won't be as easy as it sounds due to preprocessor conditionals et. al.) Thanks!
Re: CVS commit: src
On 2/17/12 7:11 PM, Julio Merino wrote: On 2/17/12 6:42 PM, Matt Thomas wrote: On Feb 17, 2012, at 3:11 PM, Julio Merino wrote: On 2/17/12 6:06 PM, Matt Thomas wrote: On Feb 17, 2012, at 3:02 PM, Julio Merino wrote: Aha, I see. Does it make sense to keep the test after renaming PAGE_SIZE to uvmexp.pagesize? It's a public symbol after all and we really should have tests for these, I think. Do we need to go over the broken modules one by one and replace PAGE_SIZE with uvmexp.pagesize? (I'm expecting this won't be as easy as it sounds due to preprocessor conditionals et. al.) They should still use PAGE_SIZE which should evaluate to uvmexp.pagesize Now you lost me. You started saying that PAGE_SIZE is explicitly not available, and now you say that the modules have to use PAGE_SIZE? The problem is that PAGE_SIZE is NOT being evaluated to uvmexp.pagesize as you mention. It's being evaluated to uvmexp_pagesize, which does not exist and thus causes the module to not load. And that's what this test is all about. Hmmm. I think uvmexp_pagesize, etal is there to avoid needed uvmexp defined. The problem was: --- uvm_param.h 29 Nov 2011 07:43:54 - 1.26 +++ uvm_param.h 17 Feb 2012 23:40:50 - @@ -134,7 +134,7 @@ * If MIN_PAGE_SIZE and MAX_PAGE_SIZE are not equal, then we must use * non-constant PAGE_SIZE, et al for LKMs. */ -#if (MIN_PAGE_SIZE != MAX_PAGE_SIZE) defined(_LKM) +#if (MIN_PAGE_SIZE != MAX_PAGE_SIZE) (defined(_LKM) || defined(MODULAR)) #undef PAGE_SIZE #undef PAGE_MASK #undef PAGE_SHIFT I have applied this patch and rebuilt the affected test module... and it still won't load. Wasn't that supposed to be _MODULE instead of MODULAR? Oh, but even doing that change, the module won't load either. PAGE_SIZE still ends up being defined as uvmexp_pagesize... which I believe is correct, right? because the size must be represented as a variable... but that variable is not available in the built kernel.
Re: CVS commit: src
On 2/7/12 2:37 PM, Joerg Sonnenberger wrote: Module Name:src Committed By: joerg Date: Tue Feb 7 19:37:14 UTC 2012 Modified Files: src: UPDATING src/doc: CHANGES Log Message: Add note about new apropos and mandoc for formatting. Document failing update builds due to the cat page removal. This leaves tons of garbage behind in destdir (as you said), but provides no migration path for already-installed systems. How do you expect people to clean up their system from the already-installed cat pages and databases? I don't see any postinstall changes either. Files in DESTDIR but missing from flist. File is obsolete or flist is out of date ? -- ./usr/libexec/getNAME ./usr/libexec/makewhatis ./usr/share/man/cat*/* ./usr/share/man/html8/getNAME.html ./usr/share/man/html8/makewhatis.html ./usr/share/man/makewhatis.sed ./usr/share/man/man8/getNAME.8 ./usr/share/man/man8/makewhatis.8 ./usr/share/man/whatis.db
Re: CVS commit: src/external/bsd/atf/dist/atf-run
On 12/19/11 10:25 PM, Christos Zoulas wrote: Module Name: src Committed By: christos Date: Mon Dec 19 22:25:46 UTC 2011 Modified Files: src/external/bsd/atf/dist/atf-run: timer.cpp Log Message: - make all the ifdefs match - make it compile, and test This was still broken. timer_t and itimerspec do not exist, so the timer.hpp file is unusable. The definition of HAVE_POSIX_TIMER does not work because SIGEV_NONE is defined in OS X. The change of sys/time.h and signal.h to ctime and csignal seems to cause issues too. I have had to fix this by adding a configure test for timer_t, using the pimpl idiom for the timer class definition to prevent further ifdef mess in timer.hpp, and had to sprinkle some more ifdef stuff in the code. The result is incredibly ugly, and I doubt there is any real benefit other than using modern interfaces. Was it really worth it? (I have not committed these fixes to the NetBSD tree because I cannot test them at the moment.) -- Julio Merino / @jmmv
Re: CVS commit: src/external/bsd/atf/dist/atf-run
On Sun, Dec 18, 2011 at 10:34 PM, Christos Zoulas chris...@netbsd.orgwrote: Module Name:src Committed By: christos Date: Sun Dec 18 22:34:06 UTC 2011 Modified Files: src/external/bsd/atf/dist/atf-run: timer.cpp timer.hpp Log Message: Don't use antiquated BSD API's that require global variable, use posix timers instead. Interesting; didn't know about these. But what's the point of this change? It breaks OS X at least and does not fix anything AFAICT. -- Julio Merino / @jmmv
Re: CVS commit: src/external/bsd/atf/dist/atf-run
On Mon, Dec 19, 2011 at 5:58 PM, Christos Zoulas chris...@zoulas.comwrote: On Dec 19, 5:00pm, j...@netbsd.org (Julio Merino) wrote: -- Subject: Re: CVS commit: src/external/bsd/atf/dist/atf-run | Interesting; didn't know about these. | | But what's the point of this change? It breaks OS X at least and does not | fix anything AFAICT. I am just trying to use modern POSIX API's to improve portability Well... modern has come to mean less portable in my book. (I like using modern APIs, but they tend to break grgrgr.) (and functionality in this case). For example, by using sigevent, one doesn't need to have global variables and he can pass the struct he wants to modify in the signal. In addition, one can use the monotonic clock, which is immune against time changes, and also use timespec which is more precise. Finally one is not limited to sigalrm for timers, but can send any signal. Thanks. I am really suprised that OS/X does not have them; I would have expected it to work on more systems than it does currently... I could only check with Snow Leopard and there is no timer_t there. I don't have access to Lion at the moment; when I do, I'll check again. If there is no support in it, I'll have to implement some conditional logic to use the new timers only if available (unless you have a better alternative?). If there is support, then I won't care about backwards compatibility. -- Julio Merino / @jmmv
Re: CVS commit: src/external/bsd/atf/dist/atf-run
On Mon, Dec 19, 2011 at 8:32 PM, Christos Zoulas chris...@zoulas.comwrote: On Dec 19, 6:06pm, j...@netbsd.org (Julio Merino) wrote: -- Subject: Re: CVS commit: src/external/bsd/atf/dist/atf-run | I could only check with Snow Leopard and there is no timer_t there. I | don't have access to Lion at the moment; when I do, I'll check again. If | there is no support in it, I'll have to implement some conditional logic to | use the new timers only if available (unless you have a better | alternative?). If there is support, then I won't care about backwards | compatibility. Since it is my fault that I broke it, I will add a shim for OS/X that does not do anything fancy and implements the previous basic functionality that setitimer had. Could you check if this support exists in Lion first? If that's the case, I personally don't think it is a big deal. But thanks if you do that! -- Julio Merino / @jmmv
Re: CVS commit: src/sys
On 11/22/11 4:25 PM, Thor Lancelot Simon wrote: Module Name: src Committed By: tls Date: Tue Nov 22 21:25:42 UTC 2011 Modified Files: [...] src/sys/conf: std Log Message: The rnd pseudo-device is not really optional, because it is in the same source file as the entropy-pool code itself. Move it to std. This will be cleaned up more when I split the sources up as they should be. This fixes build breaks on several ports. Thanks to Havard Eidnes for pointing them out. I think this deserves a note in UPDATING. If people have their own kernel configuration files, they need to know to remove 'rnd' from them in order to be able to build kernels. I just encountered this scenario and had to dig down to see if removing the entry from the file was the right thing to do. -- Julio Merino / @jmmv
Re: CVS commit: src/tests/util/sh
On 11/14/11 3:23 PM, Christos Zoulas wrote: Module Name:src Committed By: christos Date: Mon Nov 14 20:23:29 UTC 2011 Modified Files: src/tests/util/sh: Makefile Added Files: src/tests/util/sh: t_evaltested.sh Log Message: Add a test for PR/45613 (eval failing in a tested context) This looks like a poor name for the program: in general, if the test program contains a single test case and both have the same name, that's a bad symptom. Following prior art in this same directory, the program should have probably been named t_eval and the single test that it currently has tested_context. This would leave room for the future addition of eval-related tests, whereas the current naming does not.
Re: CVS commit: src/external/bsd/atf/dist
On 11/16/11 12:46 PM, Christos Zoulas wrote:
Module Name:src
Committed By: christos
Date: Wed Nov 16 17:46:16 UTC 2011
Modified Files:
src/external/bsd/atf/dist/atf-c++/detail: text.cpp text.hpp
src/external/bsd/atf/dist/atf-run: requirements.cpp test-program.cpp
Log Message:
PR/45619: jmmv: Allow atf tests to request a minimum amount of memory
Could you run intrusive changes to atf for review please?
The current changes are incomplete and inappropriate, so they are going
to make integration upstream a pain.
+int64_t
+impl::to_number(const std::string str)
+{
+ int64_t num;
+ ::dehumanize_number(str.c_str(),num);
This adds a dependency on NetBSD that should not be there.
[...]
+static
+std::string
+check_memory(const std::string memory)
+{
+// Make sure we have enough memory
+int64_t memneed = atf::text::to_number(memory);
+int64_t memavail;
+size_t len = sizeof(memavail);
+
+if (::sysctlbyname(hw.usermem64,memavail,len, NULL, 0) == -1) {
Same here and below in the same function. This is NetBSD specific and
there is no provisions to support other systems.
[...]
Lastly, this has been added without absolutely no tests and no
documentation. (And there seem to be whitespace issues, although I
can't tell if these are my mua's fault...)
Re: CVS commit: src/external/bsd/atf/dist
On 11/16/11 1:51 PM, Christos Zoulas wrote: In article4ec3f8f7.8020...@netbsd.org, Julio Merinoj...@netbsd.org wrote: On 11/16/11 12:46 PM, Christos Zoulas wrote: Module Name:src Committed By: christos Date: Wed Nov 16 17:46:16 UTC 2011 Modified Files: src/external/bsd/atf/dist/atf-c++/detail: text.cpp text.hpp src/external/bsd/atf/dist/atf-run: requirements.cpp test-program.cpp Log Message: PR/45619: jmmv: Allow atf tests to request a minimum amount of memory Could you run intrusive changes to atf for review please? The current changes are incomplete and inappropriate, so they are going to make integration upstream a pain. Well, there is really no portable way to find the total available memory of the system that I know of and I did not want to add ifdefs or machinery to get this working on other OS's. If you know otherwise, feel free to fix it. I know there is no portable way, but at least we can default to do nothing if this is not supported. It's better than not building :-P The changes are really small and they are additions only. I fail to see how it is going to be difficult to integrate. Yes, they are small because this is just one change. But more may come. I'll then have to go and rewrite all these local changes with portability in mind. When the time to integrate a new release comes, I'll have to mess around with lots merge conflicts, because the upstream code will look nothing like what we have (hence why I asked for this to be reviewed first). Of course, if we assume I keep good track of all local changes and integrate them upstream (I do try), I could ignore the local changes altogether during the conflicts resolution and use the upstream copies... but that's... dangerous because I can miss some little thing. Specially if the local changes are made without tests, because then it'll be impossible for me to spot when such changes are not preserved.
Re: CVS commit: src/external/bsd/atf/dist
On 11/16/11 3:11 PM, Christos Zoulas wrote: In article4ec40d98.4070...@netbsd.org, Julio Merinoj...@netbsd.org wrote: I know there is no portable way, but at least we can default to do nothing if this is not supported. It's better than not building :-P Oh, I can arrange that. #ifdef __NetBSD__ :-) But in my view this is worse... Yeah, leave it as is for now. I'll have to do something similar anyway though, but if I can implement the code for the most common systems, that's probably good enough. Yes, they are small because this is just one change. But more may come. I'll then have to go and rewrite all these local changes with portability in mind. When the time to integrate a new release comes, I'll have to mess around with lots merge conflicts, because the upstream code will look nothing like what we have (hence why I asked for this to be reviewed first). Well, this is the world we live in. Next time be the one to upgrade gdb or binutils or ssh and have to deal with 10-50K lines of diffs. You will not be complaining about a 100 line conflict after that :-) That's true... but do we have a chance of getting things integrated into gdb quickly and/or on our own to prevent those 10-50K diffs? For atf we do ;-) (OK, I can definitely try to improve on the quickly side...) Anyway, just something to keep in mind. Still, I'd appreciate running changes for review at least. I'm open to overlooking details like these that don't fit upstream if that's going to make things easier temporarily.
Re: CVS commit: src/external/bsd/atf/dist/atf-c
On 11/9/11 9:42 AM, Christos Zoulas wrote: Module Name:src Committed By: christos Date: Wed Nov 9 14:42:43 UTC 2011 Modified Files: src/external/bsd/atf/dist/atf-c: tc.c Log Message: need || instead of To generate a diff of this commit: cvs rdiff -u -r1.10 -r1.11 src/external/bsd/atf/dist/atf-c/tc.c Thanks; it seems to work now.
Re: CVS commit: src/external/bsd/atf/dist/atf-c
On 11/8/11 3:25 PM, Christos Zoulas wrote: In article 2007202432.ga7...@britannica.bec.de, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Mon, Nov 07, 2011 at 04:06:30PM +, Christos Zoulas wrote: Well, I tried to print the failing pattern in t_expand, and it silently got truncated. dprintf(3) has been part of TOG since 2006: (http://pubs.opengroup.org/onlinepubs/9699919799/functions/dprintf.html) So it would be preferable to implement it in terms of asprintf/write + or snprintf/malloc/write or even fdopen/fprintf instead of open coding it. From reading the patch, there are three different brances, right? Why don't you use writev for this with up to 6 elements in the vector? Done. Did you even run any tests after doing this? This is broken. The assertion you added triggers immediately. -- Julio Merino / @jmmv
Re: CVS commit: src/external/bsd/atf/dist/atf-c
On 11/8/11 7:32 PM, Christos Zoulas wrote: Yes, I did. I actually wrote the test backwards 2ice because INV has inverted logic than regular assert for some reason. It doesn't. INV(x) is the same as assert(x) -- or it is supposed to be -- but if it wasn't, things would have broken much earlier everywhere. -- Julio Merino / @jmmv
Re: CVS commit: src/external/bsd/atf/dist/atf-c
On 11/6/11 1:18 PM, Christos Zoulas wrote: Module Name:src Committed By: christos Date: Sun Nov 6 18:18:16 UTC 2011 Modified Files: src/external/bsd/atf/dist/atf-c: tc.c Log Message: don't truncate error messages to 1K. The use of dprintf cannot be merged back upstream because this function does not appear to be widely available. A bunch of write()s should have the same effect and remove the 1K limit; will do this. Anyway, where have you spot error messages longer than 1K? That seems... ugly.
Re: CVS commit: src/tests/net/net
On 9/30/11 2:17 PM, Christos Zoulas wrote: On Sep 30, 5:37pm, jruoho...@iki.fi (Jukka Ruohonen) wrote: -- Subject: Re: CVS commit: src/tests/net/net | This fails, probably because it does not follow the atf(7) API: | | tps-count: 1 | tp-start: t_unix, 2 | tc-start: sockaddr_un_len_exceed | tc-end: sockaddr_un_len_exceed, passed | tc-start: sockaddr_un_len_max | tc-end: sockaddr_un_len_max, failed, Test case exited normally but failed to | create the results file: Failed to open /tmp/atf-run.03735a/tcr | tp-end: t_unix Can you be more specific? What does it need to do? Use ATF_FAIL instead of err() to signal errors.
Re: CVS commit: src/crypto/external/bsd/netpgp/dist
On 7/21/11 4:49 AM, Martin Husemann wrote: On Thu, Jul 21, 2011 at 07:11:56AM +0100, Iain Hibbert wrote: I thought that I agreed with Jukka, it seemed to be a complaint with no specific content except that you were uncomfortable (unfamilar?) with atf. I'm mostly with Iain here, though I have a vague idea and think I partly understand the uncomfortableness on David's side. However, from my very practical experience (from all relevant sides: running tests, writing/extending them, and most importantly: fixing the troubles they show) it is not the framework that causes most problems in solving bugs, my top problem was: non working gdb (at least for threaded apps) How so? gdb with test programs should have been fixed a while ago. Or are we talking about something different?
Re: CVS commit: src/crypto/external/bsd/netpgp/dist
On 7/21/11 2:11 AM, Iain Hibbert wrote: PS the predictable consequence that you cannot fold in external test programs did not come true, see tests/lib/libevent/t_event.sh for example, though I note that the number of libevent tests are misrepresented in the atf-total since the test program prints OK rather than allowing the test harness to do each one separately And this particular concern is what has kept me busy for the last two weeks. Still not there yet, but it should soon be possible to mux atf and non-atf test programs in the same suite.
Re: CVS commit: src/crypto/external/bsd/netpgp/dist
On 6/28/11 7:25 AM, Jukka Ruohonen wrote: On Tue, Jun 28, 2011 at 08:12:26AM +0200, Alistair Crooks wrote: 3. they are candidates for modifying to work under atf, I have yet to get the time to do that 4. luke kindly made some gnu autotests for them a while ago [...] and if someone was to offer to convert these tests to atf style, that would be great, thanks. Ok. But I think this entails a wider discussion about how the tests shipped with third-party software could be integrated to atf(7). In case of netpgp(1) this is easy; a relatively small code base for which both in-house tests and /src/tests can be easily distributed. But then there are entirely different beasts like gcc(1). One of the ideas floating around in my head is to make atf-run (well, kyua) support foreign tests. The most basic form of this would be programs that just return 0 on success or 1 on failure, but maybe it'd be extended to also support autotest programs, etc. Sure, their functionality would be limited within the framework (as compared to native atf tests, but this would allow us to mux all the tests in one single run without much effort. -- Julio Merino / @jmmv
Re: CVS commit: src/crypto/external/bsd/netpgp/dist
On 6/29/11 2:59 PM, Jukka Ruohonen wrote: On Tue, Jun 28, 2011 at 06:50:50AM +, David Holland wrote: Perhaps if atf were less intrusive...? What do you mean? I think it needs to be quite intrusive (sandboxing, etc.). Unquestionably the old /regress-style is not the way to go. Even if you dislike some parts of the API, already the consistency is a big win. Yep, I had the same question here. I don't know what the original comment meant. On Wed, Jun 29, 2011 at 10:50:22AM +0100, Julio Merino wrote: One of the ideas floating around in my head is to make atf-run (well, kyua) support foreign tests. The most basic form of this would be programs that just return 0 on success or 1 on failure, but maybe it'd be extended to also support autotest programs, etc. Wasn't there already a test or two doing something like this? Fine by me, as long as we do not regress to the old /regress-style in which it is usually hard to even know what is being tested. Some atf-ified tests do look like this, yes, and it's ugly. But if we could do this, we could lower the barrier of entry (specially for third-party projects): you could plug in a simple test program that you already have and get it to work inside atf, later refining it. Also, using foreign test programs does not preclude the sandboxing. The sandboxing is something that must be in place all the time IMHO regardless of how the tests are written. Sure, their functionality would be limited within the framework (as compared to native atf tests, but this would allow us to mux all the tests in one single run without much effort. But in reality, the gcc(1) test suite is probably the only one that would really be worth considering. NetBSD does not ship that much third-party software, and the availability of tests is generally quite limited among this group. Maybe true, but I'd personally like to see all the available tests running, even if they are not sophisticated enough. (Otherwise, why are we importing them at all?) -- Julio Merino / @jmmv
Re: CVS commit: src/external/bsd/atf/dist/atf-c/detail
On 6/16/11 3:57 PM, Joerg Sonnenberger wrote: Module Name: src Committed By: joerg Date: Thu Jun 16 14:57:22 UTC 2011 Modified Files: src/external/bsd/atf/dist/atf-c/detail: test_helpers.c Log Message: Properly use a format string. I presume you found this with clang, right? I only hit the issue in OS X and didn't bother to pull it up to NetBSD because gcc did not encounter the problem. Thanks! -- Julio Merino / @jmmv
Re: CVS commit: src/tests
On 6/15/11 3:36 AM, Christos Zoulas wrote: On Jun 14, 5:14am, jruoho...@iki.fi (Jukka Ruohonen) wrote: -- Subject: Re: CVS commit: src/tests | On Sat, Jun 11, 2011 at 02:03:20PM -0400, Christos Zoulas wrote: | Log Message: | Turn warns on for all tests and fix all the bugs. | | Thanks for the cleanup. | | Now the wscrl-test (lib/libcurses/t_curses) however fails: | Peeling though the layers and trying to figure out what's going on is really annoying. So: Let's start: t_curses is a shell script. Try to run it from source: $ cd /usr/src/tests/lib/libcurses $ atf-run obj.amd64/t_curses atf-run: ERROR: Cannot open Atffile $ cd /usr/src/tests/lib/libcurses $ make test Beautiful, we have a command that takes arguments from the command line, the environment, and has default arguments, that I need to read the source to find them. I won't bore you any more with this, but I am still peeling layers of brown cylindrical items to find out what's going on with the test program. Surely, there must be a simpler way to isolate the test program that is running so that I can run it by hand and debug it! So what is it? I'm not sure how the curses tests work, but based on what you show above they seem complex. In general, just doing the t_foo bar dance is enough for debugging. -- Julio Merino / @jmmv
Re: CVS commit: src/tests/kernel
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? I always thought that having a single unified tests-directory was a benefit, not a disadvantage. What is the advantage? Just to make things clear, tests would still be installed to /usr/tests so that they can all be run at once. Moving the tests right next to the source does not really solve any of the questions; for instance, where would system calls go? libc? sys/kern? Just like for manpages, it makes sense in some cases and it doesn't in others. I don't think it'd be bad to keep cross-layer/tool tests in a src/tests directory but move anything that is clearly tool-specific next to the source. (It's much easier for people to edit a cp_test.c file when they are editing cp.c if they see the file right there, whereas it is easy/annoying to have to hunt down the test file in a different subtree. I've used/seen both approaches, if that matters at all.) -- Julio Merino / @jmmv
Re: CVS commit: src/tests/syscall
On 5/29/11 1:57 PM, Matthias Scheler wrote: Modified Files: src/tests/syscall: t_pollts.c Log Message: [...] Also use ATF_REQUIRE_EQ_MSG() instead of ATF_REQUIRE_MSG() to avoid crashes if one of the required conditions isn't met. It could be a bug in the macro. I tried changing the last ATF_REQUIRE_EQ_MSG call in the program to ATF_REQUIRE_MSG but it did not fail. And I tried adding an explicitly-failing ATF_REQUIRE_MSG and did not see a crash either... Could you provide some more details and/or a stack trace please? -- Julio Merino / @jmmv
Re: CVS commit: src/tests/kernel
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 the tests. What goes in syscalls, what goes in sys, and what goes in kernel? I think we should follow the userland location for paths where those should be defined, so everything should go into libc/sys. Yes, we have. It's in my to-do list to write a proposal to clean this mess (hopefully soon). One thing is reorganizing the tests to match the tree structure, but the other is to move the tests right next to the source (like we did with manpages). -- Julio Merino / @jmmv
Re: CVS commit: src
On 5/28/11 10:46 PM, Christos Zoulas wrote: In article20110528161256.ab89817...@cvs.netbsd.org, Matthias Schelersource-changes-d@NetBSD.org wrote: + assert(pipe(fds) == 0); [...] + assert(write(fds[1], , 1) == 1); [...] + assert(close(fds[0]) == 0); + assert(close(fds[1]) == 0); [...] + assert(sigfillset(mask) == 0); [...] + assert(sigprocmask(SIG_SETMASK, NULL,mask) == 0); [...] + assert(close(fd) == 0); Please don't create assertions that contain code, because compiled with -DNDEBUG they vanish. Are these test code? If so, just replace assert by one of: - ATF_REQUIRE(boolean_expression) - ATF_REQUIRE_EQ(expected_value, actual_value) like: ATF_REQUIRE(pipe(fds) != 0); ATF_REQUIRE_EQ(1, write(fds[1], , 1)); -- Julio Merino / @jmmv
Re: CVS commit: src
On 5/26/11 5:25 AM, Masao Uebayashi wrote: Module Name:src Committed By: uebayasi Date: Thu May 26 04:25:28 UTC 2011 Modified Files: src/share/man/man5: boot.cfg.5 src/share/man/man8/man8.i386: boot.8 src/sys/arch/i386/stand/boot: boot2.c src/sys/arch/i386/stand/lib: bootmenu.c exec.c libi386.h src/sys/arch/i386/stand/pxeboot: main.c src/sys/arch/x86/include: bootinfo.h cpu.h src/sys/arch/x86/x86: x86_machdep.c src/sys/kern: init_main.c subr_userconf.c src/sys/sys: userconf.h Log Message: Support userconf(4) command in boot(8)/boot.cfg(5) on i386/amd64. From jmmv@, no objections seen in the proposed thread: http://mail-index.netbsd.org/tech-kern/2009/01/22/msg004081.html Wow. Looks like I didn't remember to submit this at the time. Thanks!
Re: CVS commit: src
On 5/26/11 5:10 PM, Lars Heidieker wrote:
Hi,
with those changes I can't compile a kernel without USERCONF option set.
The changes in x86_machdep.c should be with in if defs on that options
Ok to commit the attached patch?
@@ -178,6 +182,7 @@ module_init_md(void)
}
#endif/* MODULAR */
+#if defined(USERCONF)
void
userconf_bootinfo(void)
{
@@ -197,6 +202,7 @@ userconf_bootinfo(void)
userconf_parse(bi-text);
}
}
+#endif /* defined USERCONF) */
Missing ( before USERCONF.
Also, this is defining userconf_bootinfo conditionally. Did you
validate that all callers are protected by USERCONF as well? (An
alternative would be to make the body of userconf_bootinfo conditional,
not the function itself.
Re: CVS commit: src/tests/syscall
On 5/22/11 12:48 AM, Christos Zoulas wrote: On May 22, 12:28am, j...@julipedia.org (Julio Merino) wrote: -- Subject: Re: CVS commit: src/tests/syscall | That's what was done. But in order to enforce the timeouts et. al. this | library had to fork() on every test case. This was really, really ugly | (and slow) in shell. It was also hard to keep the 3 implementations (c, | c++, shell) in sync. You should not have to fork if you don't set a timeout. Or you can fork just one killer and have it timeout in 2x the last registered timeout and exit. It listens to a socket for pid's and timeouts; if the socket is still useable after the timeout it kills. One of the original design goals of atf was to explicitly run every test case in a subprocess. The idea was to prevent broken test cases from corrupting the results of other tests. So yes, you have to fork (if only because it's in the requirements of the design) ;-) I had actually thought about the alternative you mention not too long ago, but if you do that, then a misbehaving test case will result in the termination of the whole test program (you need to kill a particular process after all). Maybe it's not a big deal since that's what other very-popular frameworks do, but it's a complete shift in how atf currently works. Anyway. We are getting side-tracked here; I was just trying to see if we had a bug in atf. If you want to discuss this further, the topic needs to be moved to atf-devel.
Re: CVS commit: src/distrib/sets/lists/xserver
On 5/20/11 10:28 AM, Izumi Tsutsui wrote: Module Name:src Committed By: tsutsui Date: Fri May 20 09:28:32 UTC 2011 Modified Files: src/distrib/sets/lists/xserver: md.zaurus Log Message: Add /etc/X11/xorg.conf. This should be in xetc, shouldn't it? Otherwise people will lose any local changes they do when they extract xserver.tgz. (I see other platforms installing xorg.conf-something from xserver.tgz, but I presume those are to be treated as examples.) -- Julio Merino / @jmmv
Re: CVS commit: src/tests/lib/libobjc
On 5/20/11 2:03 PM, Joerg Sonnenberger wrote: Module Name:src Committed By: joerg Date: Fri May 20 13:03:45 UTC 2011 Modified Files: src/tests/lib/libobjc: Makefile Log Message: Test case requires the GCC specific thread extension for Objective C, so only enable the test if GCC is present and disable other compiler. Tests should always run and report 'skipped' when they can't for whatever reason. This test should have a #ifdef around the code and fall back to a simple atf_tc_skip. -- Julio Merino / @jmmv
Re: CVS commit: src/tests/syscall
On Wed, May 18, 2011 at 12:30:24PM +, Christos Zoulas wrote: In article 4dd39547.9010...@julipedia.org, Julio Merino j...@julipedia.org wrote: On 5/18/11 4:15 AM, Christos Zoulas wrote: Module Name: src Committed By: christos Date: Wed May 18 03:15:12 UTC 2011 Modified Files: src/tests/syscall: t_pselect.c Log Message: Don't depend on the atf timeout stuff, do it ourselves. Why? Could atf do something better here? 1. It did not work. What units is the timeout anyway? I waited 2 seconds and 2 minutes and it did not fire. It's in seconds. The default is 300. You can override the timeout by setting the 'timeout' metadata property to a different value. 2. I need to do some cleanup if there is a timeout (kill the stuck process). How do I register a cleanup function? Use ATF_TC_WITH_CLEANUP and then provide an ATF_TC_CLEANUP function for your test case. Be aware that cleanup runs in a different process than the body, so the only way to transfer state is through a file in the current directory. 3. No matter how the timeout is done (unless you start a watcher process and kill -KILL the test process) it can break (masking signal mask, changing timers, catching signal). The timeout is enforced from atf-run, not from inside the test case; it is already using a helper process in a sense, so it should work. If it doesn't, it is a bug that I'd like to debug. -- Julio Merino
Re: CVS commit: src/distrib/sets/lists/xserver
On 5/21/11 12:04 PM, Izumi Tsutsui wrote: Modified Files: src/distrib/sets/lists/xserver: md.zaurus Log Message: Add /etc/X11/xorg.conf. This should be in xetc, shouldn't it? Otherwise people will lose any local changes they do when they extract xserver.tgz. Hmm. I chose xorg.conf because there were very few NetBSD/zaurus users and there was no model specific hardware settings, so I thought less manual configuration was better to start Xserver after install. That's fine, but either the Xserver should just DTRT without a configuration file (like in does in other platforms), or the configuration file should really be treated as such. But if guys really claim we should keep a correct style in any case I'll rename it. Keeping it as xorg.conf is fine as long as it is in xetc.tgz. You don't want to screw up user-modified configuration files when they unpack xserver.tgz ;-) -- Julio Merino / @jmmv
Re: CVS commit: src/tests/syscall
On 5/21/11 3:19 PM, Christos Zoulas wrote: In article20110521083602.ga24...@netbsd.org, Julio Merinoj...@netbsd.org wrote: 1. It did not work. What units is the timeout anyway? I waited 2 seconds and 2 minutes and it did not fire. It's in seconds. The default is 300. I think the unit is too long for modern hardware. Imaging having 300 tests needing 1 second timeouts. Yes, the timeout thing is broken. It should really be a specification of the test case size (e.g. 'small', 'large') and allow the user to define his timeout preferences for every class, because they will vary from machine to machine. That said, I don't see why you'd want to have 300 tests needing 1-second timeouts. If a test times out, it's broken, so the only thing I can deduce is that you'd have 300 broken tests ;-) 3. No matter how the timeout is done (unless you start a watcher process and kill -KILL the test process) it can break (masking signal mask, changing timers, catching signal). The timeout is enforced from atf-run, not from inside the test case; it is already using a helper process in a sense, so it should work. If it doesn't, it is a bug that I'd like to debug. Revert the latest revision in the test and boot a kernel before the pselect changes, and see it getting stuck. Any particular revision? I have a machine that hasn't been updated for at least two weeks; will that be enough? Thanks. -- Julio Merino / @jmmv
Re: CVS commit: src/tests/syscall
On 5/21/11 5:25 PM, David Laight wrote: On Sat, May 21, 2011 at 05:14:07PM +0200, Manuel Bouyer wrote: On Sat, May 21, 2011 at 03:34:22PM +0100, Julio Merino wrote: Yes, the timeout thing is broken. It should really be a specification of the test case size (e.g. 'small', 'large') and allow the user to define his timeout preferences for every class, because they will vary from machine to machine. Sure. I ran ATF on a machine with a 1Mhz CPU clock (this is a simulator, the real hardware is expected to run faster :). Lots of tests timed out just because on such hardware they can't complete in less than 5mn. Perhaps the timeout(s) should be settable units that default to 1 second. Them the timeouts can be scaled for very slow (or fast) systems. Perhaps. But timeouts in a measure of time do not make sense in this context. There won't be any way to scale them in a reliable manner, so this will lead to flaky tests. And anyway, the user will be required to have control over how long these deadlines are. Again, there is no point in setting test timeouts to 1 second (except for very very rare cases). Timeouts are only used to kill tests that get stuck; nothing should rely on them. If there is many timeouts in your test suite (which will result in failed tests), something is broken and needs fixing. -- Julio Merino / @jmmv
Re: CVS commit: src/tests/syscall
On 05/21/11 15:44, Christos Zoulas wrote: On May 21, 3:34pm, j...@netbsd.org (Julio Merino) wrote: -- Subject: Re: CVS commit: src/tests/syscall | On 5/21/11 3:19 PM, Christos Zoulas wrote: | Revert the latest revision in the test and boot a kernel before the pselect | changes, and see it getting stuck. | | Any particular revision? I have a machine that hasn't been updated for | at least two weeks; will that be enough? Oh sure. revision 1.1 Alright, so I just tried this. Downgraded the test to 1.1 and ensured that my kernel does not have the fix (sys_select.c:1.30 and sys_sig.c:1.32). And the timeout of 2 seconds works just fine. Just to make sure we are talking about the same: you were running the test program with atf-run; correct? If yes, what platform was this in? (I'm testing with amd64.) Otherwise, this is expected behavior: tests are not supposed to be executed without atf-run.
Re: CVS commit: src/tests/syscall
On 05/21/11 21:58, Christos Zoulas wrote: On May 21, 9:26pm, j...@julipedia.org (Julio Merino) wrote: -- Subject: Re: CVS commit: src/tests/syscall | Just to make sure we are talking about the same: you were running the | test program with atf-run; correct? If yes, what platform was this in? | (I'm testing with amd64.) Otherwise, this is expected behavior: tests | are not supposed to be executed without atf-run. No, I am running it directly. Programs could warn if they figured out that they are not running under atf-run. Print something like: not running under atf-run, timeouts will not work. Sounds like a good idea. Note that there is *many* more things that will not work. The test case will dump garbage in the current directory and it won't be cleaned, the environment won't be sanitized, child processes won't be killed... Also it would be nice if programs when invoked with -l or something they would list all their tests, and if That already works :-) The output format is gly though invoked with -a they would run all the tests. Tests used to do exactly that more than a year ago, but it turned out to be a bad idea... The test programs were extremely complex: they had to implement all the test case isolation (work directory, timeouts, etc.) themselves, and that meant having to implement the same thing in C, C++ and shell. Also, and this is what bugged most people: debugging the test cases was almost impossible due to all the black magic that was involved in them. The test cases would delete temporary files on failure and gdb was unusable. As a result, I moved all the isolation logic into atf-run and turned the test programs into a 'dumb' frontend for the test cases. Test programs now don't do much more than just running test case bodies and exposing a consistent interface, so they really should not be used directly unless you need to debug a particular test case. Oh, and the whole system works much, much faster ;-P
Re: CVS commit: src/tests/syscall
On 5/22/11 12:18 AM, Christos Zoulas wrote: On May 21, 10:31pm, j...@julipedia.org (Julio Merino) wrote: -- Subject: Re: CVS commit: src/tests/syscall | Sounds like a good idea. Note that there is *many* more things that | will not work. The test case will dump garbage in the current directory | and it won't be cleaned, the environment won't be sanitized, child | processes won't be killed... It could mention all of them. atf-test-case(4) contains a description of these. (Yeah, it could be improved.) | Tests used to do exactly that more than a year ago, but it turned out to | be a bad idea... | | The test programs were extremely complex: they had to implement all the | test case isolation (work directory, timeouts, etc.) themselves, and | that meant having to implement the same thing in C, C++ and shell. I don't see why. You just put it all in a shared library written in c and used from c++. Shell you have already. That's what was done. But in order to enforce the timeouts et. al. this library had to fork() on every test case. This was really, really ugly (and slow) in shell. It was also hard to keep the 3 implementations (c, c++, shell) in sync. I'm not saying it's not possible, just that it was ugly _in the past_. We can revisit this later. The renewed runtime I'm working on (atf v2, aka kyua) will support different test program styles, so we should be able to easily re-experiment with this approach.
Re: CVS commit: src/tests/syscall
On 5/18/11 4:15 AM, Christos Zoulas wrote: Module Name:src Committed By: christos Date: Wed May 18 03:15:12 UTC 2011 Modified Files: src/tests/syscall: t_pselect.c Log Message: Don't depend on the atf timeout stuff, do it ourselves. Why? Could atf do something better here?
Re: CVS commit: src/tests/lib/libposix
On 5/16/11 1:03 AM, Christos Zoulas wrote: Module Name:src Committed By: christos Date: Mon May 16 00:03:36 UTC 2011 Modified Files: src/tests/lib/libposix: t_rename.c Log Message: h_macros need strlcat and random ugh, please someone remove this header. define _NETBSD_SOURCE so those are defined. The original intent of h_macros was as a place to provide NetBSD-specific check macros that can't be part of the generic codebase of atf. I'm not sure what it currently includes, but I presume it does not follow this rule any more. I'll check later (FSVO later ;-) what pieces could be now moved to atf to clean this up a bit.
Re: CVS commit: src/sys/crypto/rijndael
On 5/14/11 12:27 PM, Julio Merino wrote: Module Name:src Committed By: jmmv Date: Sat May 14 16:27:50 UTC 2011 Modified Files: src/sys/crypto/rijndael: rijndael-api-fst.c Log Message: Declare for-loop control variable outside of the for statement to prevent a warning and therefore fix the build. Ah! I just saw your warns=4 change. I presume my 'fix' goes against it, right?
Re: CVS commit: src/sys/crypto/rijndael
On 5/14/11 12:31 PM, Christos Zoulas wrote: On May 14, 12:29pm, j...@julipedia.org (Julio Merino) wrote: -- Subject: Re: CVS commit: src/sys/crypto/rijndael | Declare for-loop control variable outside of the for statement to prevent | a warning and therefore fix the build. | | Ah! I just saw your warns=4 change. I presume my 'fix' goes against | it, right? Yes, you should revert it. Kernel code is supposed to use c99 features. OK; I'll do a test build before submitting the revert. I just realized that my tree already had your change when I committed this, yet the build still failed.
Re: CVS commit: src/tests/lib/libc
On Sat, Jan 8, 2011 at 6:10 PM, Paul Goyette pgoye...@netbsd.org wrote: Module Name: src Committed By: pgoyette Date: Sat Jan 8 18:10:32 UTC 2011 Modified Files: src/tests/lib/libc: Makefile Added Files: src/tests/lib/libc/regex: README debug.c main.c split.c t_regex.awk t_regex.in test_regex.h src/tests/lib/libc/regex/data: anchor.in backref.in basic.in bracket.in c_comments.in complex.in error.in meta.in nospec.in nul.in paren.in regress.in repet_bounded.in repet_multi.in repet_ordinary.in startend.in subexp.in subtle.in word_bound.in Log Message: Atf-ify the regex test I think there is a missing Makefile in this change in src/tests/lib/libc/regex/. I get complains in the checkflist stage about missing files in destdir, but surprisingly not during the build. -- Julio Merino
Re: CVS commit: src
On Sat, Jan 1, 2011 at 2:09 PM, Adam Hamsik h...@netbsd.org wrote: Module Name: src Committed By: haad Date: Sat Jan 1 13:09:13 UTC 2011 Modified Files: src/distrib/sets/lists/base: mi src/etc/mtree: NetBSD.dist.base Log Message: Add /var/lock/lvm subdir for LVM it can be created automagically but I think that it's better to have it created before. This broke the build: http://www.gson.org/netbsd/bugs/build/build/2011.01.01.20.43.01/build.log.tail -- Julio Merino
Re: CVS commit: src/tests/util/make
On 12/3/10 1:29 AM, Christos Zoulas wrote: Module Name:src Committed By: christos Date: Fri Dec 3 01:29:55 UTC 2010 Modified Files: src/tests/util/make: Makefile t_make.sh Added Files: src/tests/util/make: d_unmatchedvarparen.mk d_unmatchedvarparen.out Log Message: Add a new test for the latest variable expansion problem. - Cannot test because make test prints: .: Can't open /usr/share/atf/atf.header.subr - The shell script common code needs to be fixed to follow regular shell style. - variables are underquoted - uses `` instead of $() - does not use local for local variables, prefixes with undescore - needlessly uses braces for numeric and symbolic variables. - uses a fifo to grab output, and does not clean it up properly on error - should not exit with 127 !!! === 2 extra files in DESTDIR = Files in DESTDIR but missing from flist. File is obsolete or flist is out of date ? -- ./usr/tests/util/make/d_unmatchedvarparen.mk ./usr/tests/util/make/d_unmatchedvarparen.out = end of 2 extra files ===
Re: CVS commit: src/external/bsd/atf/dist
On Aug 26, 2010, at 4:43 PM, Paul Goyette wrote: On Thu, 26 Aug 2010, Julio Merino wrote: Module Name:src Committed By: jmmv Date: Thu Aug 26 15:28:31 UTC 2010 Modified Files: src/external/bsd/atf/dist/atf-c++: io.cpp io.hpp io_test.cpp src/external/bsd/atf/dist/atf-run: test-program.cpp Log Message: Partially pull up the following revisions that address ticket #53: 996f9c26e07a86607f373c8f0243d57329c11543 ef98529abaf16e40a2e684496bf3da8f9ff0d09c These prevent atf-run from stalling/crashing when a subprocess of a test case stays around after the test case itself exits. Reported, and verified working, by po...@. Just wondering - does this address PR bin/43802 that I just filed? Yup, but I had no idea about this PR :-P
Re: CVS commit: src
On Mon, Jul 5, 2010 at 1:53 PM, Nicolas Joly nj...@netbsd.org wrote: Module Name: src Committed By: njoly Date: Mon Jul 5 12:53:59 UTC 2010 Modified Files: src/distrib/sets/lists/tests: mi src/etc/mtree: NetBSD.dist.base src/tests/fs: Makefile Added Files: src/tests/fs/vfs: Atffile Makefile t_rmdirrace.c Log Message: Add test program that use sample code from kern/41937, and fs rump helpers to check currently supported filesystems. t_rmdirrace (1/1): 5 test cases ext2fs_race: Passed. ffs_race: Passed. msdosfs_race: Passed. sysvbfs_race: Passed. tmpfs_race: Passed. Neat! But one suggestion: test programs should have a generic name whereas the test cases should carry the more specific name. This makes it possible to reuse a test program to provide several test cases and, therefore, reduces the burden of adding new test programs every time we want to test something. In this particular case, it'd have made sense (imo) to name the test program t_rmdir and the test case race. This way, t_rmdir can very easily accommodate future tests for rmdir(2) without the need to create a test program -- and adding a single test case is trivial, but adding a test program currently is not. -- Julio Merino
