Re: Module and device configuration locking [was Re: Modules loading modules?]
Paul Goyette p...@whooppee.com 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 file. This allows inclusion of the kernel code directly into rump, rather than having to re-implement it in rump/klock.c Please use kern_cflock.c or something like that, as kern_cfg.c is too generic for such specific facility. -- Mindaugas
Using coccinelle for (quick?) syntax fixing
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 tools makes it easier to search and fix. Let's take two simple examples to illustrate what I mean: - one where I replace all sizeof(fooarray)/sizeof(foo) by its __arraycount() equivalent, provided cdefs.h is included http://www.netbsd.org/~jym/cocci/arraycount.diff - another where I am trying to detect places where aprint_* calls could be replaced by aprint_*_dev() (look for all aprint_*.diff files): http://www.netbsd.org/~jym/cocci/ I perfectly understand the limitations of the approach. It is purely cosmetic (at least in this case), risk of false positive (there are lots for the aprint_* case, coccinelle is having a hard time with format strings), and still needs proof-reading (and even testing where non trivial spatchs are applied - before getting caught by the regression test angels). However, for parts where the syntax remains generally the same, it is quite straight-forward. The cocci files are ~30 lines long, not particularly hard to read, and are quite easier to get rolling than a full sed/awk/vi/grep session. Took me a few hours to get a bit familiar with it (let's say that the documentation is an on-going effort). Opinions? Any interest in it? My intent is to put NetBSD specific scripts on wiki.n.o, and provide links for more generic ones. [1] http://wiki.netbsd.org/~jym/coccinelle/ -- Jean-Yves Migeon jeanyves.mig...@free.fr
Re: Using coccinelle for (quick?) syntax fixing
On Sun, 08 Aug 2010 18:05:11 +0200 Jean-Yves Migeon jeanyves.mig...@free.fr 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 sharing, I personally didn't know Coccinelle. And example scripts can often be more useful than plain documentation, especially if it's in a WIP state (I liked that they showed in a few lines why it's better than sed :)) -- Matt
Length of wmesg for condvar?
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_thread_cv, modunload); There appear to be several other similar violations in various places: src/sys/arch/x86/x86/ipmi.c src/sys/arch/xen/xen/balloon.c src/sys/dev/isa/fd.c src/sys/dev/tprof/tprof.c src/sys/dist/ipf/netinet/ip_auth.c src/sys/dist/ipf/netinet/ip_log.c src/sys/dist/ipf/netinet/ip_sync.c src/sys/fs/nilfs/nilfs_subr.c src/sys/fs/nilfs/nilfs_vfsops.c src/sys/kern/sys_pipe.c src/sys/net/agr/if_agr.c src/sys/opencrypto/crypto.c src/sys/rump/librump/rumpkern/sysproxy_socket.c Should these be changed? Are there any adverse effects from having a wmesg longer than 8 characters? - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
