Re: CVS commit: src/sys/uvm

2020-07-18 Thread Jukka Ruohonen
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

2020-07-16 Thread Jukka Ruohonen
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

2020-07-13 Thread Jukka Ruohonen
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

2020-07-11 Thread Jukka Ruohonen
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

2020-06-27 Thread Jukka Ruohonen
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

2020-06-24 Thread Jukka Ruohonen
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

2020-06-23 Thread Jukka Ruohonen
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

2014-04-26 Thread Jukka Ruohonen
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

2014-04-18 Thread Jukka Ruohonen
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

2014-04-14 Thread Jukka Ruohonen
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

2014-04-13 Thread Jukka Ruohonen
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

2014-04-09 Thread Jukka Ruohonen
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

2014-04-09 Thread Jukka Ruohonen
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

2014-03-21 Thread Jukka Ruohonen
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

2014-03-21 Thread Jukka Ruohonen
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

2014-03-13 Thread Jukka Ruohonen
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

2014-03-12 Thread Jukka Ruohonen
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

2014-03-02 Thread Jukka Ruohonen
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

2014-01-06 Thread Jukka Ruohonen
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

2013-12-10 Thread Jukka Ruohonen
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

2013-12-08 Thread Jukka Ruohonen
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

2013-11-25 Thread Jukka Ruohonen
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

2013-11-11 Thread Jukka Ruohonen
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

2013-11-11 Thread Jukka Ruohonen
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

2013-11-11 Thread Jukka Ruohonen

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

2013-11-10 Thread Jukka Ruohonen
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

2013-11-09 Thread Jukka Ruohonen
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

2013-10-29 Thread Jukka Ruohonen
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

2013-10-27 Thread Jukka Ruohonen
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

2013-10-25 Thread Jukka Ruohonen
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

2013-10-23 Thread Jukka Ruohonen
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

2013-10-23 Thread Jukka Ruohonen
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

2013-10-23 Thread Jukka Ruohonen
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

2013-10-20 Thread Jukka Ruohonen
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

2013-10-18 Thread Jukka Ruohonen
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

2013-10-18 Thread Jukka Ruohonen
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

2013-10-17 Thread Jukka Ruohonen
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

2013-10-17 Thread Jukka Ruohonen
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

2013-07-24 Thread Jukka Ruohonen
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

2013-07-19 Thread Jukka Ruohonen
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

2013-07-19 Thread Jukka Ruohonen
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

2013-06-05 Thread Jukka Ruohonen
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

2013-06-05 Thread Jukka Ruohonen
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

2013-06-04 Thread Jukka Ruohonen
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

2013-06-02 Thread Jukka Ruohonen
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

2013-05-31 Thread Jukka Ruohonen
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

2013-05-10 Thread Jukka Ruohonen
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

2013-03-18 Thread Jukka Ruohonen
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

2012-12-17 Thread Jukka Ruohonen
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

2012-12-14 Thread Jukka Ruohonen
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

2012-12-13 Thread Jukka Ruohonen
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

2012-12-08 Thread Jukka Ruohonen
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

2012-10-01 Thread Jukka Ruohonen
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

2012-10-01 Thread Jukka Ruohonen
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

2012-08-02 Thread Jukka Ruohonen
[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

2012-07-30 Thread Jukka Ruohonen
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

2012-07-21 Thread Jukka Ruohonen
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

2012-06-02 Thread Jukka Ruohonen
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

2012-05-31 Thread Jukka Ruohonen
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

2012-05-31 Thread Jukka Ruohonen
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

2012-05-16 Thread Jukka Ruohonen
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

2012-04-13 Thread Jukka Ruohonen
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

2012-04-02 Thread Jukka Ruohonen
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

2012-03-29 Thread Jukka Ruohonen
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

2012-03-27 Thread Jukka Ruohonen
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

2012-03-18 Thread Jukka Ruohonen
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

2012-03-18 Thread Jukka Ruohonen
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

2012-03-18 Thread Jukka Ruohonen
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

2012-03-01 Thread Jukka Ruohonen
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

2012-02-19 Thread Jukka Ruohonen
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

2012-02-12 Thread Jukka Ruohonen
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

2011-11-06 Thread Jukka Ruohonen
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

2011-11-06 Thread Jukka Ruohonen
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

2011-10-26 Thread Jukka Ruohonen
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

2011-10-25 Thread Jukka Ruohonen
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

2011-10-25 Thread Jukka Ruohonen
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

2011-10-24 Thread Jukka Ruohonen
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

2011-10-18 Thread Jukka Ruohonen
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

2011-10-18 Thread Jukka Ruohonen
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

2011-10-18 Thread Jukka Ruohonen
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

2011-10-18 Thread Jukka Ruohonen
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

2011-10-18 Thread Jukka Ruohonen
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

2011-10-18 Thread Jukka Ruohonen
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/arch/x86/x86

2011-10-18 Thread Jukka Ruohonen
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/sys/fs/puffs

2011-10-18 Thread Jukka Ruohonen
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

2011-10-12 Thread Jukka Ruohonen
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

2011-09-30 Thread Jukka Ruohonen
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

2011-09-29 Thread Jukka Ruohonen
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

2011-09-29 Thread Jukka Ruohonen
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

2011-09-23 Thread Jukka Ruohonen
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

2011-09-17 Thread Jukka Ruohonen
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

2011-09-16 Thread Jukka Ruohonen
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

2011-09-13 Thread Jukka Ruohonen
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

2011-09-13 Thread Jukka Ruohonen
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

2011-09-12 Thread Jukka Ruohonen
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

2011-09-11 Thread Jukka Ruohonen
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

2011-09-07 Thread Jukka Ruohonen
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

2011-09-03 Thread Jukka Ruohonen
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

2011-08-30 Thread 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.

- 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

2011-08-30 Thread Jukka Ruohonen
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.


  1   2   3   4   5   >