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/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 jruoho...@iki.fi 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/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 m...@eterna.com.au 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
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/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/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/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/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/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 x86/cpuvar.h
#include x86/cpu_msr.h
#include x86/machdep.h
+#include x86/x86/tsc.h
#include dev/acpi/acpica.h
#include dev/acpi/acpi_cpu.h
@@ -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 *);
--
---
SAITOH Masanobu
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 queue.h, 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
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 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
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 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 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/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 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/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: 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: 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/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/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
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 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
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/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 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 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_castt(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 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/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
[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/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 12:29:55PM +0200, Martin Husemann wrote: On Wed, May 30, 2012 at 03:11:58PM +, 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/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/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/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
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/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 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/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 string.h
#include unistd.h
#include errno.h
#include sched.h
+#include signal.h
#include sys/param.h
#include sys/types.h
@@ -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/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 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 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/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/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 bch on current-users mailing list. Wasn't there an explicit decision to enable it by default? - 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 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/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/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/arch/x86/x86
On Tue, Oct 18, 2011 at 08:43:46AM +0200, Marc Balmer wrote: Am 18.10.11 06:27, schrieb Jukka Ruohonen: On Tue, Oct 18, 2011 at 12:07:45AM +, Jared D. McNeill wrote: Module Name: src Committed By: jmcneill Date: Tue Oct 18 00:07:45 UTC 2011 Modified Files: src/sys/arch/x86/x86: vmt.c Log Message: don't allow module autounload I wonder should autounloading be prohibited for all driver-class modules? Why? When the parent goes away, why not autounload a driver? I am not sure. But have we thought about all the consequences and corner- cases? Unloading happens while modifying hardware state? Deferred calls in the drivers? And so on? To me it also seems that if I manually load a driver-module, I expect it to stay loaded until I unload it. - Jukka.
Re: CVS commit: src
On Tue, Oct 18, 2011 at 09:50:25AM +, Thomas Klausner wrote: Module Name: src Committed By: wiz Date: Tue Oct 18 09:50:25 UTC 2011 Modified Files: src/distrib/sets/lists/man: mi src/share/man/man4: Makefile Added Files: src/share/man/man4: vmt.4 Log Message: Add vmt(4) from OpenBSD. This should probably be in man4.x86. - Jukka.
Re: CVS commit: src/sys/arch/x86/x86
On Tue, Oct 18, 2011 at 06:39:49AM -0400, 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? That sounds right to me. As noted, generally I am not sure what my opinion about autounloading really is. But it feels somewhat awkward and error-prone that drivers must protect themselves against the autounloading kthread. - Jukka.
Re: CVS commit: src/sys/arch/x86/x86
On Tue, Oct 18, 2011 at 12:44:52PM +0100, Iain Hibbert wrote: The real benefit of the modular system is that you don't need to load hundreds of modules on the off chance that they will be used. A cron entry could be used to flush unused modules if the sysop cares about that, why do we need a kthread running? A good question worth asking. And as far as I remember, the autounloading cycle was as low as 10 seconds (!), whereas a proper scale would be measured in minutes or hours in my opinion (or even as daily(5)). - Jukka.
Re: CVS commit: src/sys/arch/x86/x86
On Tue, Oct 18, 2011 at 07:59:35AM -0400, Jared D. McNeill wrote: Well I loaded vmt manually and it was auto unloaded on me a few minutes later, that's why I made this change in the first place. On 2011-10-18, at 7:57 AM, Paul Goyette wrote: On Tue, 18 Oct 2011, Jukka Ruohonen wrote: On Tue, Oct 18, 2011 at 06:39:49AM -0400, 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? That sounds right to me. I was under the impression that we would already only auto-unload modules that were auto-loaded. The comment in module_thread() says * Automatically unload modules. We try once to unload autoloaded * modules after module_autotime seconds. ... True. But like Jared, I've also seen magic unloading of some of my driver modules. I guess there is a bug somewhere. - 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.
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/external/bsd/cron/dist
On Wed, Oct 12, 2011 at 12:39:48PM -0400, Christos Zoulas wrote: Module Name: src Committed By: christos Date: Wed Oct 12 16:39:48 UTC 2011 Modified Files: src/external/bsd/cron/dist: cron.8 database.c pathnames.h Log Message: process files in /etc/cron.d/ Not that I see much point in the whole commit, but what are these rpms and how they are related to NetBSD? - Jukka. +Finally +.Nm +looks for crontabs in +.Pa /etc/cron.d +if it exists, and executes each file as a crontab. +.Pp +When +.Nm +looks in a directory for crontabs (either in +.Pa /var/cron/tabs +or +.Pa /etc/cron.d ) +it will not process files that: +.Bl -dash -compact -offset indent +.It +Start with a +.Sq \. +or a +.Sq # . +.It +End with a +.Sq ~ +or with +.Dq .rpmsave , - ??? +.Dq .rpmorig , - ??? +or +.Dq .rpmnew . - ??? +.It
Re: CVS commit: src/tests/net/net
On Wed, Sep 28, 2011 at 12:13:03PM -0400, Christos Zoulas wrote: Module Name: src Committed By: christos Date: Wed Sep 28 16:13:03 UTC 2011 Modified Files: src/tests/net/net: Makefile Added Files: src/tests/net/net: t_unix.c Log Message: Add a unix socket pathname size limit test. 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 - Jukka.
Re: CVS commit: src
On Thu, Sep 29, 2011 at 10:51:25PM +0200, Jean-Yves Migeon wrote: Blocking kmem is not necessarily a bug is you hold an adaptive lock. Your mutex is IPL_NONE, if I remember correctly. You probably don't need to be smart. I am not sure that this lock will be released if the LWP needs to sleep for the allocation. Which means that the lock will block other LWPs from running even when they do not need to allocate memory. Of course I can preallocate the structure and avoid the issue this way. But similar issues seem to be widely present in the detach/deregister-type routines (another example: drvctl_close() in kern_drvctl.c). - Jukka.
Re: CVS commit: src
On Thu, Sep 29, 2011 at 10:56:48PM +0100, Alexander Nasonov wrote: Elements must go in descendant order but since values of CPUFREQ_STATE_DISABLED and CPUFREQ_STATE_ENABLED are unspecified, the manual should explicitly state in which order these two states should go. True. Every time you skip cf-cf_state element, you have a gap in the Oh, true. The documentation is clear about cf_state elements, why do you need to skip entries at all and make your life harder? Just return error or add KASSERT if a caller doesn't follow the docs. I moved it here so that code can be shared. This must be done somewhere for things that rely on firmware for the values; any kind of garbage can follow, but you don't want to abort the whole thing due a single mistake done by the BIOS writer. - Jukka.
Re: CVS commit: src/external/bsd/bind/dist/lib/isc/include/isc
On Wed, Sep 14, 2011 at 08:32:44AM +0100, David Laight wrote:
On Tue, Sep 13, 2011 at 03:07:44PM -0400, Christos Zoulas wrote:
Module Name:src
Committed By: christos
Date: Tue Sep 13 19:07:44 UTC 2011
Modified Files:
src/external/bsd/bind/dist/lib/isc/include/isc: util.h
Log Message:
Some versions of linux have probably marked fwrite(3) as
__attribute__((__warn_unused_result__))
What sort of moonshine are those guys on?
Checking the result of fwrite() (and fprintf()) for error is often
pointless since the error doesn't happen until the data is written.
While this case may be dubious, I think the __warn_unused_result__ attribute
is generally useful. It might even reveal a security bug one day. The lousy
practices of not checking return values were probably the reason for the
invention of exceptions and try {} catch {} -idioms, etc...
- Jukka.
Re: CVS commit: src/lib/libm/man
On Sat, Sep 17, 2011 at 03:32:22PM +0200, Thomas Klausner wrote: Remove rest of the NOTES and ERRORS and references to pow(3) family. Why did you remove so much of the explanations in the man page? Because much of it was outdated or incomplete, and the rest was what others have criticized of being man page spam (i.e. implementation details). - Jukka.
Re: CVS commit: src/tests/lib/libm
On Fri, Sep 16, 2011 at 09:02:37AM +, Martin Husemann wrote: I am not sure if this is correct here. While some tests rely on NAN and similar IEEE 754 specific properties of the underlying floating point format should not be build (or skipped) on vax, this test case does not have any reason not to build on vax (AFAICT). At least this should be documented (PR, or src/doc/HACKS) and probably tanf() for VAX added (should not be that hard). Is there any consistent way to know which functions are available on VAX? Or even more generally, any consistent way to know which libm(3) functions are available on which architectures? (That is, there are ugly hacks like #ifdef i386 || sparc || amd64 too.) - Jukka.
Re: CVS commit: src/tests/lib/libm
On Tue, Sep 13, 2011 at 08:38:07AM +0200, Marc Balmer wrote:
Am 12.09.11 18:28, schrieb Jukka Ruohonen:
Module Name:src
Committed By: jruoho
Date: Mon Sep 12 16:28:37 UTC 2011
Modified Files:
src/tests/lib/libm: t_ldexp.c t_scalbn.c t_tanh.c
Log Message:
Happiness of VAX implies ugliness of the code.
But does it make the VAX really happy, if all the code is just ifdef'ed
out? Or did I get that wrong that the tests are now simply disabled on
the vax?
You are right. I didn't bother to do atf_tc_skip() for the special case of
VAX. If any of the VAX people want to run the tests, please feel free to fix.
- Jukka.
To generate a diff of this commit:
cvs rdiff -u -r1.2 -r1.3 src/tests/lib/libm/t_ldexp.c \
src/tests/lib/libm/t_scalbn.c
cvs rdiff -u -r1.4 -r1.5 src/tests/lib/libm/t_tanh.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Modified files:
Index: src/tests/lib/libm/t_ldexp.c
diff -u src/tests/lib/libm/t_ldexp.c:1.2 src/tests/lib/libm/t_ldexp.c:1.3
--- src/tests/lib/libm/t_ldexp.c:1.2Mon Sep 12 15:47:14 2011
+++ src/tests/lib/libm/t_ldexp.cMon Sep 12 16:28:37 2011
@@ -1,4 +1,4 @@
-/* $NetBSD: t_ldexp.c,v 1.2 2011/09/12 15:47:14 jruoho Exp $ */
+/* $NetBSD: t_ldexp.c,v 1.3 2011/09/12 16:28:37 jruoho Exp $ */
/*-
* Copyright (c) 2011 The NetBSD Foundation, Inc.
@@ -29,7 +29,7 @@
* POSSIBILITY OF SUCH DAMAGE.
*/
#include sys/cdefs.h
-__RCSID($NetBSD: t_ldexp.c,v 1.2 2011/09/12 15:47:14 jruoho Exp $);
+__RCSID($NetBSD: t_ldexp.c,v 1.3 2011/09/12 16:28:37 jruoho Exp $);
#include math.h
#include limits.h
@@ -49,6 +49,7 @@
ATF_TC_BODY(ldexp_nan, tc)
{
+#ifndef __vax__
const double x = 0.0L / 0.0L;
double y;
size_t i;
@@ -59,6 +60,7 @@
y = ldexp(x, exps[i]);
ATF_CHECK(isnan(y) != 0);
}
+#endif
}
ATF_TC(ldexp_inf_neg);
@@ -69,11 +71,13 @@
ATF_TC_BODY(ldexp_inf_neg, tc)
{
+#ifndef __vax__
const double x = -1.0L / 0.0L;
size_t i;
for (i = 0; i __arraycount(exps); i++)
ATF_CHECK(ldexp(x, exps[i]) == x);
+#endif
}
ATF_TC(ldexp_inf_pos);
@@ -84,11 +88,13 @@
ATF_TC_BODY(ldexp_inf_pos, tc)
{
+#ifndef __vax__
const double x = 1.0L / 0.0L;
size_t i;
for (i = 0; i __arraycount(exps); i++)
ATF_CHECK(ldexp(x, exps[i]) == x);
+#endif
}
ATF_TC(ldexp_zero_neg);
@@ -99,6 +105,7 @@
ATF_TC_BODY(ldexp_zero_neg, tc)
{
+#ifndef __vax__
const double x = -0.0L;
double y;
size_t i;
@@ -110,6 +117,7 @@
ATF_CHECK(x == y);
ATF_CHECK(signbit(y) != 0);
}
+#endif
}
ATF_TC(ldexp_zero_pos);
@@ -120,6 +128,7 @@
ATF_TC_BODY(ldexp_zero_pos, tc)
{
+#ifndef __vax__
const double x = 0.0L;
double y;
size_t i;
@@ -131,6 +140,7 @@
ATF_CHECK(x == y);
ATF_CHECK(signbit(y) == 0);
}
+#endif
}
ATF_TC(ldexpf_nan);
@@ -141,6 +151,7 @@
ATF_TC_BODY(ldexpf_nan, tc)
{
+#ifndef __vax__
const float x = 0.0L / 0.0L;
float y;
size_t i;
@@ -151,6 +162,7 @@
y = ldexpf(x, exps[i]);
ATF_CHECK(isnan(y) != 0);
}
+#endif
}
/*
@@ -165,11 +177,13 @@
ATF_TC_BODY(ldexpf_inf_neg, tc)
{
+#ifndef __vax__
const float x = -1.0L / 0.0L;
size_t i;
for (i = 0; i __arraycount(exps); i++)
ATF_CHECK(ldexpf(x, exps[i]) == x);
+#endif
}
ATF_TC(ldexpf_inf_pos);
@@ -180,11 +194,13 @@
ATF_TC_BODY(ldexpf_inf_pos, tc)
{
+#ifndef __vax__
const float x = 1.0L / 0.0L;
size_t i;
for (i = 0; i __arraycount(exps); i++)
ATF_CHECK(ldexpf(x, exps[i]) == x);
+#endif
}
ATF_TC(ldexpf_zero_neg);
@@ -195,6 +211,7 @@
ATF_TC_BODY(ldexpf_zero_neg, tc)
{
+#ifndef __vax__
const float x = -0.0L;
float y;
size_t i;
@@ -206,6 +223,7 @@
ATF_CHECK(x == y);
ATF_CHECK(signbit(y) != 0);
}
+#endif
}
ATF_TC(ldexpf_zero_pos);
@@ -216,6 +234,7 @@
ATF_TC_BODY(ldexpf_zero_pos, tc)
{
+#ifndef __vax__
const float x = 0.0L;
float y;
size_t i;
@@ -227,6 +246,7 @@
ATF_CHECK(x == y);
ATF_CHECK(signbit(y) == 0);
}
+#endif
}
ATF_TP_ADD_TCS(tp)
Index: src/tests/lib/libm/t_scalbn.c
diff -u src/tests/lib/libm/t_scalbn.c:1.2 src/tests/lib/libm/t_scalbn.c:1.3
--- src/tests/lib/libm/t_scalbn.c:1.2 Mon Sep 12 15:47:14 2011
+++ src/tests/lib/libm/t_scalbn.c Mon Sep 12 16:28:37 2011
@@ -1,4 +1,4 @@
-/* $NetBSD: t_scalbn.c,v 1.2 2011/09/12 15:47:14 jruoho Exp $ */
+/* $NetBSD
Re: CVS commit: src/tests/lib/libm
On Tue, Sep 13, 2011 at 06:50:41AM +, Jukka Ruohonen wrote: Module Name: src Committed By: jruoho Date: Tue Sep 13 06:50:41 UTC 2011 Modified Files: src/tests/lib/libm: t_scalbn.c Log Message: Test that scalbn(x) == ldexp(2) whenever FLT_RADIX == 2 (like it should be on all systems except exotic relics such as IBM 360). Ehm. scalbn(x) == ldexp(x) obviously. - Jukka.
Re: CVS commit: src/lib/libm/man
On Mon, Sep 12, 2011 at 08:00:53PM +0200, Joerg Sonnenberger wrote: On Mon, Sep 12, 2011 at 02:44:27PM +, Jukka Ruohonen wrote: Module Name:src Committed By: jruoho Date: Mon Sep 12 14:44:27 UTC 2011 Modified Files: src/lib/libm/man: ldexp.3 Log Message: Update and improve, and note that the long double variant is not supported. Can we please *not* add such notes? They don't really add value, the lack of a long double prototype at the beginning of the man page is indicator enough. They do add just another thing to keep track of when adding the support though. Fair enough. But I think it is a BUG worth mentioning when an operating system does not support standard C. - Jukka.
Re: CVS commit: src/lib/libc/stdio
On Mon, Sep 12, 2011 at 02:41:07AM +, David Holland wrote: On Sun, Sep 11, 2011 at 07:37:06AM +, Jukka Ruohonen wrote: Modified Files: src/lib/libc/stdio: funopen.3 Log Message: It is not just funopen(3) that is a BSDism. While that's true, those functions aren't specific to .Nx; AFAIK they were in 4.4. True enough. But I've generally followed NetBSD-specific vs. standard dichotomy. In the ideal case one could mention if a function is available in OpenBSD, FreeBSD, Solaris, Linux, etc. too, but we have enough trouble maintaining .Nx alone. - Jukka.
Re: CVS commit: src/share/man/man4
On Wed, Sep 07, 2011 at 09:24:22AM +, David Holland wrote: The purpose of GENERIC is (and has been since before Linux was invented) to include all drivers and features that can reasonably be expected to work. Drivers and other code that are commented out in GENERIC (or not present at all) will be assumed to not work. Users and sysadmins know this. Trying to retrain them all is futile. Maybe instead of philosophical argumentation, you could actually look at the GENERIC configuration files. Most of the things that are commented out are not because of brokenness but either because these have a limited value or because there is no plug'n'play or other type of autoconfiguration. The fact that Linux has always done this wrong is not a reason to go chasing after them and reinventing their mistakes. As usual, you managed to marvellously miss the point. The reason Linux does this (right) is the amount of device drivers and other components that exceed the ones in NetBSD by several factors. - Jukka.
Re: CVS commit: src/share/man/man4
On Fri, Sep 02, 2011 at 11:23:08PM -0700, John Nemeth wrote: In NetBSD, GENERIC kernels generally contain everything that could possibly be useful and doesn't cause problems (some newer drivers are buggy, some interfere with other devices, and some have caused damage to hardware). This means the question is very simple: is the driver brand new, or does it cause problems in some way? If the answer is no to both questions, then the driver is included; there are no other factors to the decision. Note that cause problems in some way does not include consuming resources such as wired kernel memory. So if everything is clear and rational, care to explain why for instance GATEWAY and IPSEC are commented out? And as said, my drivers will be an exception. - Jukka.
Re: CVS commit: src/sys/arch
On Tue, Aug 30, 2011 at 06:28:20AM -0400, Jared McNeill wrote: Uh? The bktr driver works fine and the cards are still useful and they drivers are not modularized. But in my opinion, like many things, it is not something to be enabled by default in the GENERIC kernels. - Jukka. -Original Message- From: Jukka Ruohonen Sent: Tuesday, August 30, 2011 4:01 AM Newsgroups: gmane.os.netbsd.devel.cvs.full To: source-changes-full-qavaossjccednm+yrof...@public.gmane.org Subject: CVS commit: src/sys/arch Module Name: src Committed By: jruoho Date: Tue Aug 30 08:01:13 UTC 2011 Modified Files: src/sys/arch/amd64/conf: GENERIC src/sys/arch/i386/conf: GENERIC Log Message: Comment out the legacy bktr(4) from the GENERICs. To generate a diff of this commit: cvs rdiff -u -r1.334 -r1.335 src/sys/arch/amd64/conf/GENERIC cvs rdiff -u -r1.1049 -r1.1050 src/sys/arch/i386/conf/GENERIC Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. Modified files: Index: src/sys/arch/amd64/conf/GENERIC diff -u src/sys/arch/amd64/conf/GENERIC:1.334 src/sys/arch/amd64/conf/GENERIC:1.335 --- src/sys/arch/amd64/conf/GENERIC:1.334 Thu Aug 18 20:55:21 2011 +++ src/sys/arch/amd64/conf/GENERIC Tue Aug 30 08:01:13 2011 @@ -1,4 +1,4 @@ -# $NetBSD: GENERIC,v 1.334 2011/08/18 20:55:21 jakllsch Exp $ +# $NetBSD: GENERIC,v 1.335 2011/08/30 08:01:13 jruoho Exp $ # # GENERIC machine description file # @@ -22,7 +22,7 @@ options INCLUDE_CONFIG_FILE # embed config file in kernel binary -#ident GENERIC-$Revision: 1.334 $ +#ident GENERIC-$Revision: 1.335 $ maxusers 64 # estimated number of users @@ -1032,8 +1032,8 @@ # TV cards # Brooktree 848/849/878/879 based TV cards -bktr* at pci? dev ? function ? -radio* at bktr? +#bktr* at pci? dev ? function ? +#radio* at bktr? # Conexant CX2388[0-3]-based DTV cards #cxdtv* at pci? dev ? function ? Index: src/sys/arch/i386/conf/GENERIC diff -u src/sys/arch/i386/conf/GENERIC:1.1049 src/sys/arch/i386/conf/GENERIC:1.1050 --- src/sys/arch/i386/conf/GENERIC:1.1049 Sat Aug 27 09:28:55 2011 +++ src/sys/arch/i386/conf/GENERIC Tue Aug 30 08:01:13 2011 @@ -1,4 +1,4 @@ -# $NetBSD: GENERIC,v 1.1049 2011/08/27 09:28:55 mbalmer Exp $ +# $NetBSD: GENERIC,v 1.1050 2011/08/30 08:01:13 jruoho Exp $ # # GENERIC machine description file # @@ -22,7 +22,7 @@ options INCLUDE_CONFIG_FILE # embed config file in kernel binary -#ident GENERIC-$Revision: 1.1049 $ +#ident GENERIC-$Revision: 1.1050 $ maxusers 64 # estimated number of users @@ -1433,8 +1433,8 @@ # TV cards # Brooktree 848/849/878/879 based TV cards -bktr* at pci? dev ? function ? -radio* at bktr? +#bktr* at pci? dev ? function ? +#radio* at bktr? # Conexant CX2388[0-3]-based DTV cards #cxdtv* at pci? dev ? function ?
Re: CVS commit: src/share/man/man4
On Tue, Aug 30, 2011 at 03:42:34PM +0300, Jukka Ruohonen wrote: mplayer, MythTV, VDR, Kaffeine, VLC, Totem, you name it -- won't work. Correction: mplayer may work. I have couple of these cards and if time permits, I might consider a dtv(4) rewrite. - Jukka.
Re: CVS commit: src/sys/arch
On Tue, Aug 30, 2011 at 03:14:53PM +0200, Marc Balmer wrote: Am 30.08.11 12:33, schrieb Jukka Ruohonen: On Tue, Aug 30, 2011 at 06:28:20AM -0400, Jared McNeill wrote: Uh? The bktr driver works fine and the cards are still useful and they drivers are not modularized. But in my opinion, like many things, it is not something to be enabled by default in the GENERIC kernels. My standpoint is that working drivers should be enabled by default (new ones maybe after some field testing). So users can make the best use of NetBSD. They have some hardware, and NetBSD just supports it. Well, we are still waiting core@'s resolution for the last case. So I guess there is currently no policy whatsoever regarding GENERICs (and MONOLITHIC oxymorons). - Jukka.
