Re: CVS commit: src/sys/uvm
On Sat, Jul 18, 2020 at 05:19:07PM +0900, Rin Okuyama wrote: > For most (all?) ports, these specifiers are exposed only for > _KERNEL and friends. So, inttypes(*3*) would not be the best > place for them. Currently, I'm not sure where they should be. > /usr/share/misc/style? Perhaps a new inttypes(9)? Another option would be a split akin to types(3). - Jukka
Re: CVS commit: src/sys/uvm
On Thu, Jul 16, 2020 at 05:02:18PM +1000, matthew green wrote:
> thanks! i'll try to remember we have PRIxPADDR because i
> considered looking for it and thought we didn't have it...
The whole { PRIxPADDR, PRIxPSIZE, ..., PRIxREGISTER } family
should probably be documented in inttypes(3)?
- Jukka
Re: CVS commit: src/libexec/httpd
On Mon, Jul 13, 2020 at 07:15:45PM +1000, matthew green wrote: > i'm not sure i agree about 500 -> abusive behaviour. that's > when there's some _internal_ error and could just as easily > be caused by a human or code error on the server side. > > i don't know blocklist well enough to suggestion what we > should do here, but this feels wrong to me. Sure, though I think there are no clear definitions here. For 401, on the other hand, blocklistd(8) can be useful, given that bruteforcing passwords of embedded devices is supposedly a common scenario. - Jukka
Re: CVS commit: src/sys/dev/scsipi
On Sat, Jul 11, 2020 at 02:31:46PM +, Kimmo Suominen wrote:
> Use case 2: A Linode boot profile with multiple disks results in
> the first disk ("sda") on LUN 1, while the second disk ("sdb") is
> on LUN 0, each on their own bus.
As Linode is quite popular, and supposedly uses a rather similar setup to
its competitors (e.g., Vultr), I'd reckon a pullup to NetBSD 9 would be in
order? Some of these (e.g., netcup.eu in Europe) even offer off-the-shelf
NetBSD 9 images.
- Jukka
Re: CVS commit: src/tests/lib/libc/stdlib
On Sat, Jun 27, 2020 at 10:39:08AM +, m...@netbsd.org wrote: > > Add the default TNF copyright (2005), cf. PR misc/55419. > > I don't think we can generally do this. Can you clarify if you discussed > this with the author in commit messages? Well, the committer is christos, and I doubt he cares. But as noted in the test, this 15 year old code snippet is from another person. Like with many test cases, I suppose it was originally taken/modified from a PR or a mailing list. As I noted in PR misc/55419, the problem is generic. I doubt whether it is even possible to contact all people whose code appears in src/tests. But I guess at least all NetBSD people should add the meta-data if they have code in src/tests. - Jukka
Re: CVS commit: src/tests/usr.sbin
On Wed, Jun 24, 2020 at 03:05:45PM +, Martin Husemann wrote: > Modified Files: > src/tests/usr.sbin/stdethers: Makefile > src/tests/usr.sbin/stdhosts: Makefile > > Log Message: > Add input files Ups. I try to be more careful, now that I again remember the nitty-gritties. - Jukka
Re: CVS commit: src/sys/dev/acpi
On Mon, Jun 22, 2020 at 04:14:18PM +, Maxime Villard wrote: > Module Name: src > Committed By: maxv > Date: Mon Jun 22 16:14:18 UTC 2020 > > Modified Files: > src/sys/dev/acpi: acpi.c > > Log Message: > Fix memory leak. Found by kLSan. > + > + default: > + ACPI_FREE(devinfo); > + break; > } > > return AE_OK; I think it leaks more, i.e. AcpiGetObjectInfo() always allocates a buffer. - Jukka
Re: CVS commit: src
On Tue, Jun 10, 2014 at 11:53:15PM +0200, Joerg Sonnenberger wrote: > I don't see a point in that. They are not for human consumption. Then they shouldn't be in sysctl. - Jukka.
Re: CVS commit: src/sys
On Fri, Apr 25, 2014 at 11:54:59PM +, Taylor R Campbell wrote: > Module Name: src > Committed By: riastradh > Date: Fri Apr 25 23:54:59 UTC 2014 > > Modified Files: > src/sys/dev/ic: apple_smc.c > src/sys/external/bsd/drm2/dist/drm/i915: intel_bios.c > src/sys/external/bsd/drm2/include/linux: dmi.h init.h > src/sys/external/bsd/drm2/linux: files.drmkms_linux > Added Files: > src/sys/external/bsd/drm2/linux: linux_dmi.c > > Log Message: > Implement Linux dmi_check_system API. > > Use it to get a Thinkpad quirk for i915 graphics. > > Patch from nonoka@, PR 48708. Hmm, I wonder should we adopt Linux's DMI wholesale? Not a big thing, but the constants seem more usable than strings. - Jukka.
Re: CVS commit: src/sys/arch/x86/acpi
On Thu, Apr 17, 2014 at 12:01:24PM -0400, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Thu Apr 17 16:01:24 UTC 2014 > > Modified Files: > src/sys/arch/x86/acpi: acpi_cpu_md.c > > Log Message: > CID/1203191: Out of bounds read Oh, nasty. The code was pretty much copy-pasted from ../x86/x86/est.c, which might be therefore worth to briefly check too. - Jukka.
Re: CVS commit: [tls-earlyentropy] src/distrib/utils/sysinst
On Fri, Apr 11, 2014 at 07:14:41AM -0400, Greg Troxel wrote: > All of this feels awkward. Basically it belongs in var, so I wonder > about having a /rootvar or something in the root fs in the case when > /var is not, and then /rootvar/db/entropy-file Please no more root-level directories! Once upon a time, /cdrom perhaps sounded like a good idea... - Jukka.
Re: CVS commit: src/sys/external/bsd/drm2
On Thu, Apr 10, 2014 at 04:29:23AM +, Taylor R Campbell wrote: >Date: Wed, 9 Apr 2014 20:30:24 +0300 >From: Jukka Ruohonen > >On Fri, Apr 04, 2014 at 11:47:47AM +, Taylor R Campbell wrote: >> For now, yes. I can make it a sysctl, but do you have a suggestion >> for how to enable it at boot? We don't have any notion of module >> parameters like Linux does. > >Hmm. modload(8)? > > Thanks, I stand corrected. Can parameters be passed in boot.cfg? The > i386/boot(8) man page is a little unclear to me. Supposedly yes, but someone else needs to fill in the details. I do not know what is the current state of the module discussion, but there are bigger issues looming in the shadow. At least there is no systematic way to pass the parameters (cf. /etc/modprobe.d in Linux). I think dholland@ was at some point discussing comparable config(1) issues. If there would be a systematic way, it would be easy to modularize for instance the whole ISA stack, whereas now hardcoded parameters make this impossible in practice. There are also many benefits. Take the recent addition of tpm(4) as an example: it hardcodes irq 7, and thus old school setups with parallel printers are broken by design. - Jukka.
Re: CVS commit: src/sys
On Tue, Apr 01, 2014 at 05:59:34PM +, Taylor R Campbell wrote: > (That code was based on a userland version using i386_iopl, inb, and > outb which I did confirm to work; I've just never run it in-kernel.) A manual page or an entry to ALL/GENERIC might be reasonable (perhaps with the word "experimental"). - Jukka.
Re: CVS commit: src/sys/external/bsd/drm2
On Fri, Apr 04, 2014 at 11:47:47AM +, Taylor R Campbell wrote: >Date: Fri, 04 Apr 2014 11:06:45 +1100 >from: matthew green > >"Taylor R Campbell" writes: >> Enable drm debug output iff boothowto has AB_DEBUG set. > >does this mean i can only get drm debug output when i >turn on all the other debug modules? it would be nice >to only have to turn on drm debug.. > > For now, yes. I can make it a sysctl, but do you have a suggestion > for how to enable it at boot? We don't have any notion of module > parameters like Linux does. Hmm. modload(8)? - Jukka.
Re: CVS commit: src/sys/external/bsd/acpica/dist/tables
On Fri, Mar 21, 2014 at 05:01:51PM +0200, Jukka Ruohonen wrote: > On Thu, Mar 20, 2014 at 01:40:02PM +, Taylor R Campbell wrote: > > Module Name:src > > Committed By: riastradh > > Date: Thu Mar 20 13:40:02 UTC 2014 > > > > Modified Files: > > src/sys/external/bsd/acpica/dist/tables: tbutils.c > > > > Log Message: > > Don't unmap Rsdp until we've finished using it. > > > > XXX Let me know how this is supposed to be upstreamed if you know and > > have time... > > You must post it to de...@acpica.org. I intended to write 'might'. - Jukka.
Re: CVS commit: src/sys/external/bsd/acpica/dist/tables
On Thu, Mar 20, 2014 at 01:40:02PM +, Taylor R Campbell wrote: > Module Name: src > Committed By: riastradh > Date: Thu Mar 20 13:40:02 UTC 2014 > > Modified Files: > src/sys/external/bsd/acpica/dist/tables: tbutils.c > > Log Message: > Don't unmap Rsdp until we've finished using it. > > XXX Let me know how this is supposed to be upstreamed if you know and > have time... You must post it to de...@acpica.org. - Jukka.
Re: CVS commit: src/sys/miscfs/genfs
On Thu, Mar 13, 2014 at 04:01:33AM +, David Holland wrote: > On Wed, Mar 12, 2014 at 08:11:26AM -0700, Paul Goyette wrote: > > >>Me, too. But I'd rather that we had the equivalent ISCLR() macro, too, > > >>to remove another negation/complement. > > > > > >So is ISCLR when passed two bits true if both are clear, or if it's just > > >not the case that both are set? > > > > > >Arguably this points out that the ISSET docs should explain about using > > >2 bits at once. > > > > Or might we need ISANYCLR() vs ISALLCLR() (technically, AREALLCLR() > > but that's just an English grammar nit!) > > > > :) > > By the time you finish with that you just have an alternate and less > legible expression syntax... Indeed, cf. iso646(3) :). - Jukka.
Re: CVS commit: src/sys/miscfs/genfs
On Wed, Mar 12, 2014 at 09:39:23AM +, Juergen Hannken-Illjes wrote: > Module Name: src > Committed By: hannken > Date: Wed Mar 12 09:39:23 UTC 2014 > > Modified Files: > src/sys/miscfs/genfs: layer_vnops.c > > Log Message: > Restructure layer_lock() to always lock before testing for dead node. > Use ISSET() to test flags, add assertions. As I wrote in the manual page, I'd rather see ISSET(3) et. al. disappear, i.e. these obscure rather than clarify... - Jukka.
Re: CVS commit: src/tests/lib/libm
On Sat, Mar 01, 2014 at 09:08:39PM +, David Laight wrote: > Log Message: > Some of the acos() tests seem to fail on some systems. > Sorting out why isn't helped by the tests not reporting the erronous value. > Change the 'boilerplate' pattern used so that all the values are output. > Reduce the amount of faffy red tape as well. > Some of these reductions could be shared with other libm tests, but for > the moment they are defined in this file. > All these tests pass on my amd64 system, and when I run amd64 qemu. This sounds like a good idea to remove boilerplate, i.e. a small-scale API for all of the libm-tests. (Though the stuff behind the boilerplate is justified as there has been so many bugs with these cornercase inf/NaN/etc.). - Jukka.
Re: CVS commit: src/tests/lib/libc/ssp
On Fri, Jan 10, 2014 at 10:45:34AM +, Martin Husemann wrote: > Module Name: src > Committed By: martin > Date: Fri Jan 10 10:45:34 UTC 2014 > > Modified Files: > src/tests/lib/libc/ssp: t_ssp.sh > > Log Message: > In the strcat test, smash the stack more severely (this all may depend > on alignment and stack frame details). > The gcc folks disagree with this test in general: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59750 I got a bit lost with Jelinek's reply above. Aren't those tests specifically for NetBSD's ssp(3), a.k.a. -D_FORTIFY_SOURCE=2 and not -fstack-protector? - Jukka.
Re: CVS commit: src/distrib/sets/lists/modules
On Sat, Jan 04, 2014 at 06:35:51PM +, David Holland wrote: > > I don't know 'solaris' either. That line was present in the file > > before I made any changes. > > It's the compat glop used by zfs. (I believe.) It would indeed be useful if everyting in modstat(8)'s output would have a corresponding manual page. Most do, though. - Jukka.
Re: CVS commit: src
On Mon, Jan 06, 2014 at 02:50:33PM +, Andreas Gustafsson wrote: > Module Name: src > Committed By: gson > Date: Mon Jan 6 14:50:33 UTC 2014 > > Modified Files: > src/distrib/sets/lists/debug: mi > src/distrib/sets/lists/tests: mi > src/tests/lib/libc/net: Makefile t_hostent.sh > Added Files: > src/tests/lib/libc/net: h_dns_server.c > > Log Message: > Make t_hostent test cases that query the DNS work on systems with no > Internet connectivity, by hijacking DNS queries and /etc/resolv.conf > accesses using librumphijack and providing a minimal DNS server to > answer the queries. +/* XXX the daemon2_* functions should be in a library */ + +int __deamon2_detach_pipe[2]; + [...] Why not daemon(3)? - Jukka.
Re: CVS commit: src/sys/arch/x86/x86
On Tue, Dec 10, 2013 at 02:02:41PM +0900, Masanobu SAITOH wrote:
> How about the following patch? Is it ok to commit?
Looks good to me!
- Jukka.
> Index: sys/arch/x86/acpi/acpi_cpu_md.c
> ===
> RCS file: /cvsroot/src/sys/arch/x86/acpi/acpi_cpu_md.c,v
> retrieving revision 1.74
> diff -u -r1.74 acpi_cpu_md.c
> --- sys/arch/x86/acpi/acpi_cpu_md.c 20 Nov 2013 13:52:30 - 1.74
> +++ sys/arch/x86/acpi/acpi_cpu_md.c 10 Dec 2013 04:55:11 -
> @@ -43,6 +43,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -162,6 +163,16 @@
>*/
> val |= ACPICPU_FLAG_C_APIC | ACPICPU_FLAG_C_TSC;
>
> + /*
> + * Detect whether TSC is invariant. If it is not, we keep the flag to
> + * note that TSC will not run at constant rate. Depending on the CPU,
> + * this may affect P- and T-state changes, but especially relevant
> + * are C-states; with variant TSC, states larger than C1 may
> + * completely stop the counter.
> + */
> + if (tsc_is_invariant())
> + val &= ~ACPICPU_FLAG_C_TSC;
> +
> switch (cpu_vendor) {
>
> case CPUVENDOR_IDT:
> @@ -214,24 +225,6 @@
> val &= ~ACPICPU_FLAG_C_APIC;
> }
>
> - /*
> - * Detect whether TSC is invariant. If it is not,
> - * we keep the flag to note that TSC will not run
> - * at constant rate. Depending on the CPU, this may
> - * affect P- and T-state changes, but especially
> - * relevant are C-states; with variant TSC, states
> - * larger than C1 may completely stop the counter.
> - */
> - x86_cpuid(0x8000, regs);
> -
> - if (regs[0] >= 0x8007) {
> -
> - x86_cpuid(0x8007, regs);
> -
> - if ((regs[3] & __BIT(8)) != 0)
> - val &= ~ACPICPU_FLAG_C_TSC;
> - }
> -
> break;
>
> case CPUVENDOR_AMD:
> @@ -284,13 +277,10 @@
> case 0x15: /* AMD Bulldozer */
>
> /*
> - * Like with Intel, detect invariant TSC,
> - * MSR-based P-states, and AMD's "turbo"
> - * (Core Performance Boost), respectively.
> + * Like with Intel, detect MSR-based P-states,
> + * and AMD's "turbo" (Core Performance Boost),
> + * respectively.
>*/
> - if ((regs[3] & CPUID_APM_TSC) != 0)
> - val &= ~ACPICPU_FLAG_C_TSC;
> -
> if ((regs[3] & CPUID_APM_HWP) != 0)
> val |= ACPICPU_FLAG_P_FFH;
>
> Index: sys/arch/x86/x86/tsc.c
> ===
> RCS file: /cvsroot/src/sys/arch/x86/x86/tsc.c,v
> retrieving revision 1.34
> diff -u -r1.34 tsc.c
> --- sys/arch/x86/x86/tsc.c8 Dec 2013 04:07:38 - 1.34
> +++ sys/arch/x86/x86/tsc.c10 Dec 2013 04:55:11 -
> @@ -63,23 +63,19 @@
> .tc_quality = 3000,
> };
>
> -void
> -tsc_tc_init(void)
> +bool
> +tsc_is_invariant(void)
> {
> struct cpu_info *ci;
> uint32_t descs[4];
> uint32_t family;
> bool invariant;
>
> - if (!cpu_hascounter()) {
> - return;
> - }
> + if (!cpu_hascounter())
> + return false;
>
> ci = curcpu();
> invariant = false;
> - tsc_freq = ci->ci_data.cpu_cc_freq;
> - tsc_good = (cpu_feature[0] & CPUID_MSR) != 0 &&
> - (rdmsr(MSR_TSC) != 0 || rdmsr(MSR_TSC) != 0);
>
> if (cpu_vendor == CPUVENDOR_INTEL) {
> /*
> @@ -140,6 +136,24 @@
> }
> }
>
> + return invariant;
> +}
> +
> +void
> +tsc_tc_init(void)
> +{
> + struct cpu_info *ci;
> + bool invariant;
> +
> + if (!cpu_hascounter())
> + return;
> +
> + ci = curcpu();
> + tsc_freq = ci->ci_data.cpu_cc_freq;
> + tsc_good = (cpu_feature[0] & CPUID_MSR) != 0 &&
> + (rdmsr(MSR_TSC) != 0 || rdmsr(MSR_TSC) != 0);
> +
> + invariant = tsc_is_invariant();
> if (!invariant) {
> aprint_debug("TSC not known invariant on this CPU\n");
> tsc_timecounter.tc_quality = -100;
> Index: sys/arch/x86/x86/tsc.h
> ===
> RCS file: /cvsroot/src/sys/arch/x86/x86/tsc.h,v
> retrieving revision 1.4
> diff -u -r1.4 tsc.h
> --- sys/arch/x86/x86/tsc.h10 May 2008 16:12:32 - 1.4
> +++ sys/arch/x86/x86/tsc.h10 Dec 2013 04:55:11 -
> @@ -26,6 +26,7 @@
> * POSSIBILITY OF SUCH DAMAGE.
> */
>
> +bool tsc_is_invariant(void);
> void tsc_tc_init(void);
> void tsc_sync_ap(struct cpu_info *);
> void tsc_sync_bp(struct cpu_info *);
>
>
>
Re: CVS commit: src/sys/arch/x86/x86
On Sun, Dec 08, 2013 at 04:07:38AM +, SAITOH Masanobu wrote: > Module Name: src > Committed By: msaitoh > Date: Sun Dec 8 04:07:38 UTC 2013 > > Modified Files: > src/sys/arch/x86/x86: tsc.c > > Log Message: > Update invariant TSC detect code from both Intel and AMD documents. > The best way to check whether the TSC counter is invariant or not is to check > CPUID 8007. It might be worth to refactor this as a function, given that the code is replicated in arch/x86/acpi/acpi_cpu_md.c. - Jukkal.
Re: CVS commit: src/sys/sys
On Mon, Nov 25, 2013 at 08:27:46PM -0500, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Tue Nov 26 01:27:46 UTC 2013 > > Modified Files: > src/sys/sys: queue.h > > Log Message: > Provide TAILQ_REPLACE for tmux, from FreeBSD. This should be documented in queue(3). I am not familiar with the current discussion on , but these apparent problems would be good to also note in the manual page. After all, it is among the important BSD-API manual pages (at least I've personally often looked at it). - Jukka.
Re: CVS commit: src/sys/arch/xen/x86
Thanks for the explanation! Btw, it was not criticism but a question. - Jukka. On Mon, Nov 11, 2013 at 12:31:19PM -0800, John Nemeth wrote: > On Nov 11, 1:05pm, Jukka Ruohonen wrote: > } On Mon, Nov 11, 2013 at 02:52:30AM -0800, John Nemeth wrote: > } > My point is, if you want to know, go read the thread in port-xen@, > } > or the code. Also, what "trivial function for Xen"? > } > } The wrappers in cpufunc.S'es. > > So that would be sys/arch/amd64/amd64/cpufunc.S where the > function is wrapped with ifndef XEN, or sys/arch/i386/i386/i386func.S > which has a comment near the top that says, "These are _not_ shared > with NetBSD/xen." The Xen version of wbinvd() is located in > sys/arch/xen/x86/xenfunc.c and it is indeed a simple wrapper > function, containing the single line, xpq_flush_cache();, as I > alluded to earlier in text that you snipped. > > Xen domU kernels are essentially "userland applications" for > the Xen hypervisor. They do not have direct hardware access and > are not privileged. They must make a hypervisor "syscall" to > perform many normal kernel functions. xpq_flush_cache() did this. > However, it was using a privileged operation that only dom0 kernels > (or domU kernels that were specially granted the privilege) are > allowed to do. Even Xen dom0 kernels which are allowed direct > hardware access are basically a "userland application" for the Xen > hypervisor and must a hypervisor "syscall" for many things. Now, > I suppose I could have created a sys/arch/xen/xen/cpufunc.S with > the single function xen_wbinvd() that contains the single line > wbinvd, but why bother? > > It is apparent that you are completely unfamiliar with the > code that you are criticising, and as such this will be my last > post on the subject. I don't know if you are famailiar with > nxr.netbsd.org, but it is a great tool for chasing down things like > this. Putting wbinvd in the Definition box would have turned up > all this stuff. > > }-- End of excerpt from Jukka Ruohonen
Re: CVS commit: src/sys/arch/xen/x86
On Mon, Nov 11, 2013 at 02:52:30AM -0800, John Nemeth wrote: > My point is, if you want to know, go read the thread in port-xen@, > or the code. Also, what "trivial function for Xen"? The wrappers in cpufunc.S'es. - Jukka.
Re: CVS commit: src/sys/arch/xen/x86
On Sun, Nov 10, 2013 at 11:17:54AM -0800, John Nemeth wrote: > } x86_wbind()? Which however appears to be (icorrectly?) #ifndef'd for Xen. > > Uh, the function for Xen would be wbinvd(), which would create > a very nice infinite loop as all that function does is call > xpq_flush_cache(). This change was fully discussed on tech-xen@. My point kind of was that why not fix the trivial function for Xen instead of a direct asm() call? - Jukka.
Re: CVS commit: src/sys/arch/xen/x86
On Sun, Nov 10, 2013 at 01:19:13AM +, John Nemeth wrote: > Module Name: src > Committed By: jnemeth > Date: Sun Nov 10 01:19:13 UTC 2013 > > Modified Files: > src/sys/arch/xen/x86: x86_xpmap.c > > Log Message: > Change xpq_flush_cache to just do WBINVD letting the hypervisor trap and > handle it as MMUEXT_FLUSH_CACHE is a privileged hypervisor operation. x86_wbind()? Which however appears to be (icorrectly?) #ifndef'd for Xen. - Jukka.
Re: CVS commit: src/common/lib/libc/arch/arm/atomic
On Fri, Nov 08, 2013 at 10:42:52PM +, Matt Thomas wrote: > Log Message: > Add support for the gcc __sync builtins. A stupid but important question: what is __sync? - Jukka.
Re: CVS commit: src/usr.bin/flock
On Tue, Oct 29, 2013 at 12:02:15PM -0400, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Tue Oct 29 16:02:15 UTC 2013 > > Modified Files: > src/usr.bin/flock: flock.c > > Log Message: > PR/48351: Dennis Ferguson: Fix incorrect parsing of flock flags. > XXX: still flock -s 0 fails with EINVAL, why? On the other hand, regression tests for these issues seem easy enough... :p - Jukka.
Re: CVS commit: src/distrib/sets
On Sun, Oct 27, 2013 at 09:29:42AM +, Alan Barrett wrote: > Module Name: src > Committed By: apb > Date: Sun Oct 27 09:29:42 UTC 2013 > > Modified Files: > src/distrib/sets: Makefile > > Log Message: > Add "make sortlists", for sorting the set lists. This may be > run manually, before committing changes to the lists files. A nice small addition! Would it be possible to hack more functionality; e.g. a lint-like check that the manual page lists contain all three parts? - Jukka.
Re: CVS commit: src/sys/sys
On Fri, Oct 25, 2013 at 08:51:55AM +, Alan Barrett wrote: > Module Name: src > Committed By: apb > Date: Fri Oct 25 08:51:55 UTC 2013 > > Modified Files: > src/sys/sys: cdefs.h > > Log Message: > Add __diagused and __debugused. These are for marking variables that > are used only in diagnotic or debug code, but unused when NDEBUG is > defined, or DIAGNOSTIC is not defined, or DEBUG is not defined. I tried to collect some of these to attribute(3), which might be worth updating (or not). - Jukka.
Re: CVS commit: src/tests/lib/libc/net
On Wed, Oct 23, 2013 at 11:11:49AM -0700, Paul Goyette wrote: > Fail: stdout does not match expected value > --- /tmp/inline.19256b2013-10-23 14:25:50.0 + > +++ /tmp/check.19256a/stdout 2013-10-23 14:25:50.0 + > @@ -1 +1 @@ > -name=sixthavenue.astron.com, length=4, addrtype=2, aliases=[] > addr_list=[38.117.134.6] > +error 4 So what is this "error 4"? - Jukka.
Re: CVS commit: src/sys/arch/i386/conf
On Wed, Oct 23, 2013 at 10:37:15AM -0700, Paul Goyette wrote: > On Wed, 23 Oct 2013, Matt Thomas wrote: > > >Module Name: src > >Committed By:matt > >Date:Wed Oct 23 17:26:08 UTC 2013 > > > >Modified Files: > > src/sys/arch/i386/conf: GENERIC XEN3_DOM0 > > > >Log Message: > >Add xhci device > > When do we get a xhci(4) man page? :) Also: ALL is missing from the list. - Jukka.
Re: CVS commit: src/tests/lib/libc/net
On Sun, Oct 20, 2013 at 01:22:49PM -0400, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Sun Oct 20 17:22:49 UTC 2013 > > Modified Files: > src/tests/lib/libc/net: t_hostent.sh > > Log Message: > broadway changed addresses. Something else too: the test appears to fail consistently; e.g. http://releng.netbsd.org/b5reports/i386/build/2013.10.22.21.37.33/test.html#lib_libc_net_t_hostent_dnsbyaddrlookup4 - Jukka.
Re: CVS commit: src/sys/arch/sparc
On Sat, Oct 19, 2013 at 07:40:23PM +, matthew green wrote: > Log Message: > - remove unused but set variables. > - use __USE() where necessary. > - remove useless 'volatile' markers > > kd.c:consinit() might be wrong for old proms, but i've not > changed it really. And a continuum: it seems to me that many of these changes just add #if'0 cruft to the code. Philopsophical question: why not such delete such code? - Jukka.
Re: CVS commit: xsrc/external/mit/xdm/dist/xdm
On Fri, Oct 18, 2013 at 03:59:38PM +, Alan Barrett wrote: > Module Name: xsrc > Committed By: apb > Date: Fri Oct 18 15:59:38 UTC 2013 > > Modified Files: > xsrc/external/mit/xdm/dist/xdm: dm.c > > Log Message: > Print time_t values by casting to intmax_t and using "%ji" format. Wouldn't the "right" way be PRIdMAX from inttypes(3)? Anyways, for curiosity: is there actually a portable way across operating systems to deal with this? - Jukka.
Re: CVS commit: src/sys/modules/lua
On Fri, Oct 18, 2013 at 08:16:32AM +0100, Alexander Nasonov wrote: > First of all, the code has been imported the wrong way as I stated in > the previous email. You should properly import Lua 5.2 to sys/external/ > and then apply local changes required to run it in kernel space. I agree. Already for the sake of consistency and sanity; if one looks at at sys/modules, there is no existing code in it. On Fri, Oct 18, 2013 at 09:29:44AM +0200, Marc Balmer wrote: > This was not an import of Lua. The Lua sources already are in the tree. > When we are ready to move from Lua 5.1 to Lua 5.2, Lua 5.2 will be > imported to sys/external, as I already mentioned. Why not do things right the first time? Sounds a like a recipe for a mess. - Jukka.
Re: CVS commit: src/sys/dev/pci
On Thu, Oct 17, 2013 at 08:26:33AM +0200, Martin Husemann wrote: > On Thu, Oct 17, 2013 at 09:22:02AM +0300, Jukka Ruohonen wrote: > > > Log Message: > > > use __USE() > > > > What is __USE()? Might be worth a brief manual page... Sure, although I was thinking a brief note (with caveats) appended to the existing __UNCONST(3). - Jukka.
Re: CVS commit: src/sys/dev/pci
On Wed, Oct 16, 2013 at 03:32:30PM -0400, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Wed Oct 16 19:32:30 UTC 2013 > > Modified Files: > src/sys/dev/pci: cs4281.c > > Log Message: > use __USE() What is __USE()? Might be worth a brief manual page... - Jukka.
Re: CVS commit: src
On Wed, Jul 24, 2013 at 11:45:48AM +, Nick Hudson wrote: > Module Name: src > Committed By: skrll > Date: Wed Jul 24 11:45:48 UTC 2013 > > Modified Files: > src/doc: HACKS > src/tests/lib/libc/sys: Makefile > > Log Message: > There wasn't a codegen bug - the test program itself was buggy. > > Nothing to see hear... move along. Thanks, my bug. I am not sure why I have interpreted the size of a message to be the size of the structure. Maybe some indirect note could be added to the manual page for dummies like me. - Jukka.
Re: CVS commit: src
On Fri, Jul 19, 2013 at 08:52:22AM -0700, Matt Thomas wrote:
> There is a reason for the difference.
>
> the atomic_{set,cler} are actually atomic.
>
> the atomicly use atomic operation but since they work word-by-word
> they aren't truly atomic.
Ah, I see. Might be worth to mention this also in the manual page (if not
done already).
- Jukka.
Re: CVS commit: src
On Wed, Jul 17, 2013 at 10:36:26PM +, Matt Thomas wrote: > Log Message: > Some constification. > Add kcpuset_clone, kcpuset_insersection, kcpuset_remove, > kcpuset_ffs, kcpuset_ffs_intersecting, > kcpuset_atomicly_merge, kcpuset_atomicly_intersect, kcpuset_atomicly_remove A small nit: kcpuset_atomic_set() vs. kcpuset_atomicly_*() makes the API look a little inconsistent... I don't know which is right in terms of grammar, but the atomic_*()-versions appear to be the de facto standard. - Jukka.
Re: CVS commit: src/sys
On Wed, Jun 05, 2013 at 11:25:00AM -0400, Greg Troxel wrote: > The real decision is how many conditional options to have. Agreed. > make INET mandatory. (Of course, I don't expect you or anyone else to > fix these bugs unless you are in the mood.) I think the networking code is among the last offenders here, i.e. the bitrot/preprocessor-correlation is likely strongest in some aging parts of MD-code. - Jukka.
Re: CVS commit: src/sys
On Wed, Jun 05, 2013 at 10:24:34AM -0400, Greg Troxel wrote: > INET is really INET4. Sure; but see below. > > #ifdef INET > > ... > > #ifdef INET6 > > That's a bug; in theory one should be able to have INET6 without INET. > I did try it once several years ago, and had some trouble that I didn't > solve. Not a single instance. In any case, these again cast a shadow on the usefulness or quality of some of the #ifdefs, which are perhaps not even expected to work... or at least contribute to the bitrot that christos also noted in the commit log. - Jukka.
Re: CVS commit: src/sys
On Tue, Jun 04, 2013 at 07:11:02PM -0400, Christos Zoulas wrote: > On Jun 5, 2:06am, jruoho...@iki.fi (Jukka Ruohonen) wrote: > -- Subject: Re: CVS commit: src/sys > > | On Tue, Jun 04, 2013 at 06:47:37PM -0400, Christos Zoulas wrote: > | > While here, simplify the code and remove the IPSEC_NAT_T option; always > | > compile nat-traversal in so that it does not bitrot. > | > | By the way, while I can understand INET6, what is the purpose of INET? > | Funny that even src/sys/netinet/udp_usrreq.c claims to work without it > | (to the usual funny extent of these #ifdefs). > > I don't think that anyone has compiled INET6 recently without INET (if ever). Ah, maybe IPv6-only hosts would be the rationale then. But as you noted, it is not difficult to find cases like #ifdef INET ... #ifdef INET6 - Jukka.
Re: CVS commit: xsrc/external/mit/xauth/dist
On Sun, Jun 02, 2013 at 12:40:12AM +, Christos Zoulas wrote: > > > Reminds me: should/can __UNCONST() be revisited w.r.t. the thread below? > > > > > > http://lists.freebsd.org/pipermail/freebsd-arch/2013-May/014371.html > > > >How/why? Yes, it's unsafe. That's the *point*. > > Well, there is an advantage that the FreeBSD one has over ours. It can be > used in c++ with -Wold-style-cast, if defined as: > > #define __DECONST(t, a) const_cast(a) That, and why is it cast to an unsigned long and not uintptr_t? - Jukka.
Re: CVS commit: xsrc/external/mit/xauth/dist
On Fri, May 31, 2013 at 06:46:39AM +, matthew green wrote: > Module Name: xsrc > Committed By: mrg > Date: Fri May 31 06:46:39 UTC 2013 > > Modified Files: > xsrc/external/mit/xauth/dist: process.c > > Log Message: > apply __UNCONST() if it exists. Reminds me: should/can __UNCONST() be revisited w.r.t. the thread below? http://lists.freebsd.org/pipermail/freebsd-arch/2013-May/014371.html - Jukka.
Re: CVS commit: src/crypto/external/bsd/libsaslc/dist/src
On Fri, May 10, 2013 at 12:39:25PM -0400, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Fri May 10 16:39:25 UTC 2013 > > Modified Files: > src/crypto/external/bsd/libsaslc/dist/src: dict.c > > Log Message: > use explicit_bzero instead of memset to zero memory Can you briefly note what is __explicit_bzero(XXX) and why it should be used instead of memset(3)? - Jukka.
Re: CVS commit: src/tests/fs/common
On Mon, Mar 18, 2013 at 09:13:35PM +0100, Nicolas Joly wrote: > That make a 80 CPUs host require a thread limit value of 814 > (=261+7*79) to be able to run this test. Sounds like a serious test case - Jukka.
Re: CVS commit: src
On Mon, Dec 17, 2012 at 06:17:27PM +, Alan Barrett wrote: > Log Message: > Add shell implementations of basename and dirname to rc.subr. They > are supposed to mimic basename(1) and dirname(1), except that they > are usable before /usr/bin is mounted. This demands a question: is duplication better than restructuring /usr? - Jukka.
Re: CVS commit: src/usr.sbin/envstat
On Fri, Dec 14, 2012 at 06:18:57PM +0100, Marc Balmer wrote: > > Ironically, proper ressource managements tends to make it much easier to > > fulfill at least two of the three items... > > proper resource management is a good thing - if the code continues to run. > In this case, where the program exits, there no benefit from freeing up > memory etc. And this is the reason why I've programmed in Java. And why I like C, on the other hand. And why we have Lua in the base system. - Jukka.
Re: CVS commit: src/usr.sbin/envstat
On Thu, Dec 13, 2012 at 11:53:24AM -0800, Paul Goyette wrote: > While we're making sure to free() things, should we not also defend > against memory leaks in the case where an option is used more than once? While we are here, I wonder why sysmon(9) does not follow the common guidelines w.r.t. for instance queue(3). I know quite well that none of this is your making, but smalll refactorings like this could make the code more understandable to other people. - Jukka.
Re: CVS commit: src/sys/arch
On Sat, Dec 08, 2012 at 08:27:17AM -0600, Jonathan A. Kollasch wrote: > > #ifdef - #endif-ed. NMCA, NISA, NNPX, NIOAPIC, LAPIC, MPBIOS and > > MULTIPROCESSOR. > > > > > > To generate a diff of this commit: > > cvs rdiff -u -r1.68 -r1.69 src/sys/arch/i386/i386/db_interface.c > > cvs rdiff -u -r1.265 -r1.266 src/sys/arch/i386/i386/trap.c > > cvs rdiff -u -r1.68 -r1.69 src/sys/arch/x86/x86/bus_dma.c > > cvs rdiff -u -r1.100 -r1.101 src/sys/arch/x86/x86/cpu.c > > cvs rdiff -u -r1.13 -r1.14 src/sys/arch/x86/x86/platform.c > > src/sys/arch/i386/i386/db_interface.c:149:20: error: 'LAPIC_DEST_ALLEXCL' > undeclared (first use in this function) > > Also a good portion of these changes look as if they may need more > careful consideration. And wasn't the goal to get rid of the whole #MULTIPROCESSOR? I hope some day we manage without the C preprocessor (as the driver space has always managed via autoconf(9) etc.). - Jukka.
Re: CVS commit: src/sys/arch/i386
On Mon, Oct 01, 2012 at 12:48:24AM +, David Holland wrote: > (Also, what's the recommended usermode API for programs that want to > do power stuff?) I don't think we want a single all-encompassing tool for this. At least that is my opinion, and the general direction to which many things have gradually moved. Sensors are already handled by envsys(4), processor power management should be handled by cpuctl(8), display brightness etc. should be handled by wsconsctl(8), and so forth. This should also make portability a little bit easier than a monolithic piece such as APM. - Jukka.
Re: CVS commit: src/sys/arch/i386
On Mon, Oct 01, 2012 at 07:37:24AM +0100, David Laight wrote: > The constants from it get used for ACPI power management But the only thing used for APM in ACPI is APM emulation ;-). > and for power management on some completely unrelated hardware. Possibly > they could be moved to a different header file. That is true, and I hope non-x86 ports would convert to powerd(8) et. al. - Jukka.
Re: CVS commit: src/sys/arch/arm/include
On Wed, Aug 29, 2012 at 10:25:06PM +, Matt Thomas wrote: > Module Name: src > Committed By: matt > Date: Wed Aug 29 22:25:05 UTC 2012 > > Modified Files: > src/sys/arch/arm/include: asm.h > > Log Message: > Add __BIT(n) macro Is this really necessary? We have bits(3). - Jukka.
Re: CVS commit: src/sys
[6~ > Also, thinking to use FreeBSD code for validation (plus checking for > memwords we have). It seems to be simpler and faster: > > http://www.netbsd.org/~rmind/bpf_validate.diff It is nice that you point out to comprehensive test suite, but you don't have time nor interest to do anything about it. Of course as a brilliant coder, you don't need any documentation neither. That always tells something about the whole import (at leat where I $WORK). Sorry, had to point out the NetBSD normalities. - Jukka.
Re: CVS commit: src
On Mon, Jul 30, 2012 at 06:57:20PM +, DEGROOTE Arnaud wrote: > - not connected to pmf(9) (unable to test it) This is not nice as the same thing frequently breaks suspend and resume. Hint: registering pmf(9) and testing that 'drvctl -S' works is almost the same thing as testing with real hardware. Or better than nothing. - Jukka.
Re: CVS commit: src/regress/lib/libc/cdb
On Sat, Jul 21, 2012 at 10:22:56PM +, Mindaugas Rasiukevicius 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.) - Jukka.
Re: CVS commit: src
On Mon, Jul 09, 2012 at 12:48:32AM +1000, Simon Burge wrote: > > Add MurmurHash2 -- a non-cryptographic hash function by Austin Appleby. > > The code is taken from the upstream and is in the public domain. > > I'm curious why you've chosen MurmurHash2 instead of MurmurHash3 given the > known problems with MurmurHash2? Also, should the filename have a "2" in > it? And it does not seem OK to add stuff to libc without any documentation... - Jukka.
Re: CVS commit: src/tests/lib/libexecinfo
On Sat, Jun 02, 2012 at 02:52:29PM +, Nicolas Joly wrote: > Module Name: src > Committed By: njoly > Date: Sat Jun 2 14:52:28 UTC 2012 > > Modified Files: > src/tests/lib/libexecinfo: t_backtrace.c > > Log Message: > Adjust test for recent atf_machine (amd64) -> atf_arch (x86_64) > change. Uh. I'd sure hope we'd have a single representation for 64-bit x86. But in the mean time, if you have time, can you append to atf-config(1) to which options in uname(1) the configuration strings refer to? - Jukka.
Re: CVS commit: src/tests/lib/libexecinfo
On Thu, May 31, 2012 at 01:00:52PM +0200, Martin Husemann wrote: > Well, it worked for me ;-) > > atf_machine The machine type name detected by ATF. This should >not be tunable but is provided for symmetry with >atf_arch. My bad. It worked according to the logs too: build: OK with 360028 lines of log, install: OK, tests: 3049 passed, 92 skipped, 40 expected_failure, 1 failed, ATF output: raw, xml, html commit 2012.05.30.06.01.22 martin src/tests/lib/libexecinfo/t_backtrace.c 1.3 build: OK with 361963 lines of log, install: failed skipped, 40 expected_failure, 0 failed, ATF output: raw, xml, html http://releng.netbsd.org/b5reports/i386/commits-2012.05.html#end - Jukka.
Re: CVS commit: src/tests/lib/libexecinfo
On Thu, May 31, 2012 at 12:29:55PM +0200, Martin Husemann wrote: > On Wed, May 30, 2012 at 03:11:58PM +0000, Jukka Ruohonen wrote: > > Log Message: > > Use "atf_arch" instead of "atf_machine"; see atf-config(1). > > What is the difference? I think there is no such thing as "atf_machine". - Jukka.
Re: CVS commit: src/sys/kern
On Wed, May 16, 2012 at 09:41:11AM +, Martin Husemann wrote: > Module Name: src > Committed By: martin > Date: Wed May 16 09:41:11 UTC 2012 > > Modified Files: > src/sys/kern: sys_pipe.c > > Log Message: > Make sure we can deliver two file descriptors for pipe2() before we set > up anything special (like close on exec). > Fixes PR kern/46457. Thanks for fixing this. There is at least one other critical, 100 % reproducable, bug that allows non-root users to crash the system; PR kern/38889 (see also tests/lib/libc/sys/t_mmap; "mmap_block"). - Jukka.
Re: CVS commit: src/tests/modules
On Tue, Apr 17, 2012 at 12:59:25PM +0200, Joerg Sonnenberger wrote: > On Tue, Apr 17, 2012 at 06:23:52AM +0000, Jukka Ruohonen wrote: > > Module Name:src > > Committed By: jruoho > > Date: Tue Apr 17 06:23:52 UTC 2012 > > > > Modified Files: > > src/tests/modules: t_modctl.c > > > > Log Message: > > Avoid zero-length format string. > > This shouldn't be needed, -Wno-format-zero-length should take care of > it. Hmm. The change reverted: $ cd /usr/src/tests/modules $ make cc1: warnings being treated as errors t_modctl.c: In function 'atfu_cmd_load_body': t_modctl.c:297:2: error: zero-length gnu_printf format string *** Error code 1 - Jukka.
Re: CVS commit: src/etc/mtree
On Sat, Apr 14, 2012 at 12:14:22AM +, Paul Goyette wrote: > Module Name: src > Committed By: pgoyette > Date: Sat Apr 14 00:14:22 UTC 2012 > > Modified Files: > src/etc/mtree: NetBSD.dist.tests > > Log Message: > Create the directory for the helper program; hopefully fixes the build > break. > > XXX It's odd that k_helper3 needs to have its directory pre-created, when > XXX k_helper, k_helper2, and k_uvm don't need it... Thanks for fixing this. I was (also) kind of lost with the src/tests/modules build mechanisms... - Jukka.
Re: CVS commit: src/etc/powerd/scripts
On Tue, Apr 10, 2012 at 01:58:52PM +, Jukka Ruohonen wrote: > Module Name: src > Committed By: jruoho > Date: Tue Apr 10 13:58:52 UTC 2012 > > Modified Files: > src/etc/powerd/scripts: sensor_temperature > > Log Message: > Gracefully shutdown upon reaching critical temperature levels. Prevents few > laptops (ThinkPad T61 and x61s, among others) from hitting the in-CPU reset. FYI, this is a temporary solution; I will rework powerd(8) as planned, but it won't make to 6.0. - Jukka.
Re: CVS commit: src/dist/pdisk
On Sun, Apr 08, 2012 at 08:41:18PM +, Thomas Klausner wrote: > Module Name: src > Committed By: wiz > Date: Sun Apr 8 20:41:18 UTC 2012 > > Modified Files: > src/dist/pdisk: pdisk.c > > Log Message: > Cast argument to unsigned long for i386. Why not use %zu? - Jukka.
Re: CVS commit: src
On Tue, Apr 03, 2012 at 11:31:13AM +1000, Simon Burge wrote: > There used to be a test in regress/lib/libc/randomid/idtest.c but I > can't seem to locate that in the current source tree. That tested for > duplicate random numbers within a given number of calls to randomid(). > > I'm sure that test could be adapted for this srandom/random test case as > well. It is still there; tests/lib/libc/gen/t_randomid.c. So some duplicate tests, but shouldn't matter that much. On Fri, Mar 30, 2012 at 02:05:03PM +0400, Aleksej Saushev wrote: > I don't think Marsaglia tests fit well operating system testing. Why not? While of course RNGs may vary in their purposes, I don't see any other way but statistical sampling to test the suitability of particularly hardware RNGs that already are present in the tree. But maybe I am not thinking too hard. - Jukka.
Re: CVS commit: src
On Thu, Mar 29, 2012 at 08:40:53AM +0200, Alan Barrett wrote: > n=4 would probably be enough iterations, and I'd suggest checking Adjusted. By the way, some general RNG tests should be added too. I vaguely remember the so-called "diehard" tests somewhere from the 1990s -- perhaps something like that? - Jukka.
Re: CVS commit: src/tests/ipf
On Tue, Mar 27, 2012 at 03:38:50PM +0200, Alan Barrett wrote: > >Mark the failing tests as broken. XXX: If no one is willing to maintain > >the ipf tests, these should be removed. > > I object to this. If ipf fails its tests, then the fact should be > made clear in the test reports, not hidden by disabling the tests. Indeed. But only the maintainer knows whether these are "real" bugs or bugs in the tests. I don't know whether ipf tries to maintain binary or configuration compatibility, which seems to be the root of the failures. Frankly, I am not sure even on what is being tested (thus why all tests should be clear and/or heavily commented). > I don't know whether the bugs are in ipf or in the tests, but > either way, removing or disabling the tests seems to me to be > counter-productive. These are not disabled but marked as "bogus". The reports contain a message about the supposition that the "test case is probably broken". Apparently someone else has also reached the same conclusions, given that there was even a specific function to mark ipf-tests as bogus. - Jukka.
Re: CVS commit: src
On Thu, Feb 16, 2012 at 02:47:56AM +, Konrad Schroder wrote: > Module Name: src > Committed By: perseant > Date: Thu Feb 16 02:47:56 UTC 2012 > > Modified Files: > src/sbin/newfs_lfs: make_lfs.c > src/sys/ufs/lfs: lfs.h lfs_alloc.c lfs_bio.c lfs_segment.c lfs_vfsops.c > lfs_vnops.c > src/tests/fs/vfs: t_renamerace.c t_rmdirrace.c > > Log Message: > Pass t_renamerace and t_rmdirrace tests. FYI, today's test run shows one assertion firing: Test case: fs/vfs/t_renamerace/lfs_renamerace Duration: 15.802294 seconds Termination reason FAILED: Test program received signal 6 (core dumped) Standard output stream WARNING: the log-structured file system is experimental WARNING: it may cause system crashes and/or corrupt data panic: kernel diagnostic assertion "(ip->i_flag & IN_ADIROP) == 0" failed: file "/bracket/i386/work/2012.03.20.00.16.35/src/sys/rump/fs/lib/liblfs/../../../../ufs/lfs/lfs_vnops.c", line 2090 rump kernel halting... halted http://releng.netbsd.org/b5reports/i386/build/2012.03.20.00.16.35/test.html#fs_vfs_t_renamerace_lfs_renamerace - Jukka.
Re: CVS commit: src/lib/libc/sys
On Sat, Mar 17, 2012 at 10:04:40PM -0400, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Sun Mar 18 02:04:40 UTC 2012
>
> Modified Files:
> src/lib/libc/sys: sched.c
>
> Log Message:
> fail as the man page says sched_rr_get_interval should.
#include
#include
#include
#include
+#include
#include
#include
@@ -123,6 +124,8 @@ int
sched_rr_get_interval(pid_t pid, struct timespec *interval)
{
+ if (pid && kill(pid, 0) == -1)
+ return -1;
interval->tv_sec = 0;
interval->tv_nsec = sysconf(_SC_SCHED_RT_TS) * 1000;
return 0;
So to return to this: surely this can't be right?
- Jukka.
Re: CVS commit: src/sbin/ifconfig
On Sun, Mar 18, 2012 at 11:57:08PM +0900, Julio Merino wrote: > >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. Thanks; this was pointed out already. But I have a related question. Supposedly ATF uses something like freopen(3) to capture the output in the standard streams. Now consider this from one test I just added: $ find /etc -type f -exit $ echo $? 0 All good; exited without nothing printed to stderr and the status is zero. But this: atf_check -o ignore \ -s exit:0 -x "find /etc -type f -exit" yields tc-so:Executing command [ /bin/sh -c find /etc -type f -exit ] tc-se:Fail: incorrect exit status: 1, expected: 0 tc-se:stdout: tc-se: tc-se:stderr: tc-se:find: fts_read: Inappropriate ioctl for device tc-se: tc-end: 1332083101.965143, exit, failed, atf-check failed; see the output of the test for details So what is going on here? Likewise $ find / -exit 99 $ echo $? 99 contra atf_check -o ignore -e ignore -s exit:99 -x "find / -exit 99" and tc-so:Executing command [ /bin/sh -c find / -exit 99 ] tc-se:Fail: incorrect exit status: 1, expected: 99 tc-se:stdout: tc-se: tc-se:stderr: tc-se:find: fts_read: Inappropriate ioctl for device tc-se: tc-end: 1332083172.374247, exit_status, failed, atf-check failed; see the output of the test for details - Jukka.
Re: CVS commit: src/tests/lib/librt
On Sat, Mar 17, 2012 at 10:14:16PM -0400, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Sun Mar 18 02:14:16 UTC 2012 > > Modified Files: > src/tests/lib/librt: t_sched.c > > Log Message: > this should be fixed. Hmm. But now it fails with the third check: pid_t p = getpid(); /* * IEEE Std 1003.1-2008: if the supplied pid is zero, * the parameters for the calling process are returned. */ ATF_REQUIRE(sched_getparam(0, &s1) == 0); ATF_REQUIRE(sched_getparam(p, &s2) == 0); [HERE] ATF_REQUIRE(s1.sched_priority == s2.sched_priority); - Jukka.
Re: CVS commit: src/sbin/ifconfig
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? Fail: stderr not empty --- /dev/null 2012-03-17 15:38:12.0 + +++ /tmp/check.09347a/stderr2012-03-17 15:40:11.0 + @@ -0,0 +1 @@ +ifconfig: commit_address: getifinfo: Device not configured - Jukka.
Re: CVS commit: src/external/bsd/libevent/dist/test
On Sun, Mar 11, 2012 at 07:03:34PM +, Jukka Ruohonen wrote: > Skip the "simple timeout" test. This test case is known to fail rather > consistently when run in emulated environments such as Qemu. NB: I bluntly commented out the case, as the libevent's test suite is being run as a wrapper to atf(7), and I didn't want to start patching the sources with these system(3)-like hacks. - Jukka.
Re: CVS commit: src/common/lib/libc/string
qOn Fri, Mar 02, 2012 at 04:19:15PM +, Alan Barrett wrote: > Module Name: src > Committed By: apb > Date: Fri Mar 2 16:19:15 UTC 2012 > > Modified Files: > src/common/lib/libc/string: memset2.c > > Log Message: > Change CTASSERT to __CTASSERT (the spelling used in ), > include so that it will be defined, > and move it to a better place. > > The previous CTASSERT would never have been used because > of the ifdef. If it had been used, it would have had > unwanted effects from being just after the "static inline" > that appears when BZERO is defined. > > Also move the __RCSID to a more conventional location. And what was the resolution with all this? (cf. useless changes?). Please change the documentation too (and most of all, !). - Jukka.
Re: CVS commit: src/common/lib/libc/string
On Fri, Mar 02, 2012 at 08:10:19PM +0200, Jukka Ruohonen wrote: > And what was the resolution with all this? (cf. useless changes?). > And to the point: time to change VCS? - Jukka.
Re: CVS commit: src/doc
On Fri, Mar 02, 2012 at 07:06:31AM +, Alan Barrett wrote: > Module Name: src > Committed By: apb > Date: Fri Mar 2 07:06:31 UTC 2012 > > Modified Files: > src/doc: 3RDPARTY > > Log Message: > tzcode2012b and tzdata2012b ahve been released. > We have updated to tzdata2012b. What was the resolution with the patent issues and whatnot? - Jukka.
Re: CVS commit: src/sys/external/bsd/acpica/dist/include
On Sun, Feb 19, 2012 at 07:02:57PM +0100, Joerg Sonnenberger wrote: > On Sun, Feb 19, 2012 at 11:45:03AM -0500, Christos Zoulas wrote: > > Module Name:src > > Committed By: christos > > Date: Sun Feb 19 16:45:03 UTC 2012 > > > > Modified Files: > > src/sys/external/bsd/acpica/dist/include: acapps.h > > > > Log Message: > > Use the release date as suggested. > > XXX: I bet this is going to be broken in the next import because nobody > > will remember to fix it. > > What about putting the version number in a separate file created at > build time by grepping changes.txt? Indeed; in acpixf.h there is #define ACPI_CA_VERSION 0x20110623 - Jukka.
Re: CVS commit: src/sys/external/bsd/acpica/dist/include
On Sun, Feb 19, 2012 at 07:02:57PM +0100, Joerg Sonnenberger wrote: > On Sun, Feb 19, 2012 at 11:45:03AM -0500, Christos Zoulas wrote: > > Module Name:src > > Committed By: christos > > Date: Sun Feb 19 16:45:03 UTC 2012 > > > > Modified Files: > > src/sys/external/bsd/acpica/dist/include: acapps.h > > > > Log Message: > > Use the release date as suggested. > > XXX: I bet this is going to be broken in the next import because nobody > > will remember to fix it. > > What about putting the version number in a separate file created at > build time by grepping changes.txt? Haven't checked, but I would assume there is a preprocessor definition somewhere in the headers. - Jukka.
Re: CVS commit: src/sys/external/bsd/acpica/dist/include
On Sun, Feb 19, 2012 at 12:34:19PM +0200, Alan Barrett wrote: > On Sun, 19 Feb 2012, Christos Zoulas wrote: > >Modified Files: > > src/sys/external/bsd/acpica/dist/include: acapps.h > > > >+#ifdef ACPI_REPRO > >+#define ACPI_DATE "1 Jan 1970" > >+#else > >+#define ACPI_DATE __DATE__ > >+#endif > > Can we use a better date here, without breaking MKREPRO? Perhaps the > date of the ACPICA code? Sounds good to me, especially since ACPICA follows a version scheme based on the release date (i.e. the current in NetBSD is "20110623"). - Jukka.
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 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
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 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 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... - Jukka.
Re: CVS commit: src/share/man/man5
On Mon, Nov 07, 2011 at 10:20:38AM +0100, Joerg Sonnenberger wrote: > The majority of interesting programs already have USE_FORT=yes. But USE_FORT is not the same thing as USE_SSP. - Jukka.
Re: CVS commit: src/share/man/man5
On Sun, Nov 06, 2011 at 10:34:48PM +, Matthias Scheler wrote: > Module Name: src > Committed By: tron > Date: Sun Nov 6 22:34:48 UTC 2011 > > Modified Files: > src/share/man/man5: mk.conf.5 > > Log Message: > Stack-smash protection is not enabled by default, at least not for > the complete source-tree. > > Pointed out by on "current-users" mailing list. Wasn't there an explicit decision to enable it by default? - Jukka.
Re: CVS commit: src/tests/include
On Sun, Nov 06, 2011 at 04:18:27PM +, Jukka Ruohonen wrote: > Module Name: src > Committed By: jruoho > Date: Sun Nov 6 16:18:27 UTC 2011 > > Modified Files: > src/tests/include: t_paths.c > > Log Message: > Skip the test on sparc and point to PR port-sparc/45580. If there is someone with qemu/sparc out there, can you post uname -m? - Jukka.
Re: CVS commit: src/sys
On Tue, Oct 25, 2011 at 06:21:41PM +, Christos Zoulas wrote: > >Another nice thing would be a KPI for sampling things like this (e.g. more > >robust measures like medium, harmonic mean, etc.). Or even something that > >could enable this kind of profiling on-demand. (I know, DTrace is there.) > > I totally agree. Perhaps a SoC project? Perhaps. But on the other hand, it shouldn't be that hard. For instance, one could extend the ratecheck(9) KPI a little? - Jukka.
Re: CVS commit: src/sys
On Tue, Oct 25, 2011 at 04:04:35PM +, Christos Zoulas wrote: > In this case a simple change from: >s += ntb.tv_nsec; > to: >s += ntb.tv_nsec / 1000; > would have been sufficient since the division is outside the critical > sampling section. Heh, obviously. > Could be, but in the long term I prefer us to have only one timing > scale in the kernel to avoid conversions, confusion, and gain back > some efficiency in the basic timekeeping code which now needs to > keep track of both micros and nanos. Another nice thing would be a KPI for sampling things like this (e.g. more robust measures like medium, harmonic mean, etc.). Or even something that could enable this kind of profiling on-demand. (I know, DTrace is there.) - Jukka.
Re: CVS commit: src/sys
On Tue, Oct 25, 2011 at 02:36:50PM +, Christos Zoulas wrote: > We really want to be switching most things in the kernel to timespec from > timeval not the other way around? A case came up where the transition latencies are very high, and I'd like to still use uint64_t. The precision is hardly important here (something like 10 * usec is fine). > This is backwards as things tend to become faster instead of slower. In this case (the sampling itself) things might even become slower (i.e. more CPUs), mainly due NetBSD (xcall), but still. - Jukka.
Re: CVS commit: src/sbin/atactl
On Mon, Oct 24, 2011 at 07:13:04PM +, Jonathan A. Kollasch wrote: > Module Name: src > Committed By: jakllsch > Date: Mon Oct 24 19:13:04 UTC 2011 > > Modified Files: > src/sbin/atactl: atactl.c > > Log Message: > constify Can you follow common style guidelines and wrap longs line to 80 characters? Those long lines are painful to read with many editors. - Jukka.
Re: CVS commit: src/sys/fs/puffs
On Tue, Oct 18, 2011 at 03:39:10PM +, Emmanuel Dreyfus wrote: > Module Name: src > Committed By: manu > Date: Tue Oct 18 15:39:09 UTC 2011 > > Modified Files: > src/sys/fs/puffs: puffs_msgif.c puffs_node.c puffs_vfsops.c > puffs_vnops.c > > Log Message: > Make sure pagedaemon does not sleep for memory in puffs_vnop_sleep. > Add KASSERT on any sleeping memory allocation to check it cannot happen again. +#ifdef DIAGNOSTIC + KASSERT(curlwp != uvm.pagedaemon_lwp); +#endif Why pollute code with redundant #ifdefs? - Jukka.
Re: CVS commit: src/sys/arch/x86/x86
On Tue, Oct 18, 2011 at 08:49:39AM -0600, Warner Losh wrote: > > On Oct 18, 2011, at 4:39 AM, Jared McNeill wrote: > > I would argue that any manually loaded module shouldn't be autounloaded. > > What do you think about flagging modules as autoloaded and only > > autounloading the autoloaded ones? > > If I "manually" load a dozen drivers at boot because I have a dozen > different boards with different devices. I'd kinda like the system to > "automatically" figure out what isn't needed and unload those drivers. The general idea here probably is that you shouldn't actually load manually all those drivers, but the system should be able to autoload modules specific to your hardware. But we are not there yet. And AFAIR, neither is FreeBSD. - Jukka.
Re: CVS commit: src/share/man/man4/man4.x86
On Tue, Oct 18, 2011 at 02:25:06PM +, Thomas Klausner wrote: > Module Name: src > Committed By: wiz > Date: Tue Oct 18 14:25:06 UTC 2011 > > Modified Files: > src/share/man/man4/man4.x86: vmt.4 > > Log Message: > Fix xref; comment out cpu(4) reference, does not exist. We could write one though... If nothing else, to list the things that "attach to CPUs" via autoconf(9). - Jukka.
