Paul Goyette wrote:
> Following up on all the various comments from jmcneil@, pooka@, and
> rmind@, I've attached a revised set of diffs. The most significant
> change between this and the previous revision is the separation of the
> kernconfig_lock_*() stuff into a separate kern_cfg.c source
Dear all,
I occasionally see fixes committed for things like __arraycount() or
roundup() substitutions, done on a "per-file-per-interest" basis.
Would there be any use of fixing/cleaning (at least, kernel) code by
using devel/coccinelle [1] ?
I know, this sounds like janitor work, but using such
On Sun, 8 Aug 2010, Mindaugas Rasiukevicius wrote:
Paul Goyette wrote:
Following up on all the various comments from jmcneil@, pooka@, and
rmind@, I've attached a revised set of diffs. The most significant
change between this and the previous revision is the separation of the
kernconfig_lock_
On Sun, 08 Aug 2010 18:05:11 +0200
Jean-Yves Migeon wrote:
> Opinions? Any interest in it? My intent is to put NetBSD specific
> scripts on wiki.n.o, and provide links for more "generic" ones.
That seems like a handy tool to save time and avoid a number of
typos, if it's used right. Thanks for
The condvar(9) man page states "The wmesg argument specifies a string of
no more than 8 characters..." yet there is at least one instance in the
kernel sources where we have a wmesg long than 8 characters! In
src/sys/kern/kern_module.c in routine module_init() we have
cv_init(&module_
On Sun, 8 Aug 2010 17:23:23 -0700 (PDT)
Paul Goyette wrote:
> Should these be changed? Are there any adverse effects from having a
> wmesg longer than 8 characters?
It seems to me that the exporter of those use strncpy() (i.e.
kern/init_sysctl.c) and that the structures use WMESGLEN and
KI_WME
