re: CVS commit: src/sys/arch

2010-08-17 Thread Jean-Yves Migeon
On Tue, 17 Aug 2010 09:59:54 +1000, matthew green m...@eterna.com.au wrote: For kernel core dumps, at the present time, no; this needs thinking, and testing: - kvm(3) API will have to move from using 'unsigned long' to 'paddr_t'. I am currently checking that for all architectures except i386,

re: CVS commit: src/sys/arch

2010-08-17 Thread matthew green
am currently checking that for all architectures except i386, sizeof(paddr_t) == sizeof(u_long). sparc and 32 bit sparc64 kernels use 64 bit paddr_t. there are some mips ports that do too. you can't assume the above equality at all, not since paddr_t was introduced a decade+ ago.

Re: CVS commit: src/sys/kern

2010-08-17 Thread Antti Kantee
On Tue Aug 17 2010 at 13:17:48 +, Juergen Hannken-Illjes wrote: Module Name: src Committed By: hannken Date: Tue Aug 17 13:17:48 UTC 2010 Modified Files: src/sys/kern: vfs_subr.c Log Message: Now that ffs on disk inodes get freed in the reclaim routine it is no longer

Re: CVS commit: src/sys/kern

2010-08-17 Thread Andrew Doran
On Tue, Aug 17, 2010 at 04:45:36PM +0300, Antti Kantee wrote: On Tue Aug 17 2010 at 15:41:11 +0200, Juergen Hannken-Illjes wrote: vp-v_freelisthd = NULL; mutex_exit(vnode_free_list_lock); - if (vp-v_usecount != 0) { - /* -

Re: CVS commit: src/sys/arch

2010-08-17 Thread Andrew Doran
Hi, Why are any types other than in the pmap different between PAE and !PAE? When this was originally proposed I asked for stuff like paddr_t to be 64 bits no matter what the kernel compile settings where. Thanks. On Mon, Aug 16, 2010 at 10:45:10PM +0200, Jean-Yves Migeon wrote: On

Re: CVS commit: src/sys/kern

2010-08-17 Thread Juergen Hannken-Illjes
On Tue, Aug 17, 2010 at 04:45:36PM +0300, Antti Kantee wrote: On Tue Aug 17 2010 at 15:41:11 +0200, Juergen Hannken-Illjes wrote: vp-v_freelisthd = NULL; mutex_exit(vnode_free_list_lock); - if (vp-v_usecount != 0) { - /* -

Re: CVS commit: src/sys/kern

2010-08-17 Thread Antti Kantee
On Tue Aug 17 2010 at 16:26:10 +0200, Juergen Hannken-Illjes wrote: It's not obvious from your commit message what prevents it from gaining a reference after the lock is dropped. The interlock is taken before the freelist lock is dropped and vnodes on the free lists should never

Re: CVS commit: src/sys/arch

2010-08-17 Thread Christoph Egger
Hi, Why are any types other than in the pmap different between PAE and !PAE? When this was originally proposed I asked for stuff like paddr_t to be 64 bits no matter what the kernel compile settings where. Interesting to hear that from your side. When asked for this a debate about

Re: CVS commit: src/sys/arch

2010-08-17 Thread Mindaugas Rasiukevicius
Christoph Egger christoph_eg...@gmx.de wrote: Hi, Why are any types other than in the pmap different between PAE and !PAE? When this was originally proposed I asked for stuff like paddr_t to be 64 bits no matter what the kernel compile settings where. Interesting to hear

Re: CVS commit: src/sys/kern

2010-08-17 Thread Mindaugas Rasiukevicius
Juergen Hannken-Illjes hann...@eis.cs.tu-bs.de wrote: ... It's not obvious from your commit message what prevents it from gaining a reference after the lock is dropped. The interlock is taken before the freelist lock is dropped and vnodes on the free lists should never

Re: CVS commit: src/sys/arch

2010-08-17 Thread Jean-Yves Migeon
On Tue, 17 Aug 2010 14:26:53 +, Andrew Doran a...@netbsd.org wrote: Hi, Why are any types other than in the pmap different between PAE and !PAE? When this was originally proposed I asked for stuff like paddr_t to be 64 bits no matter what the kernel compile settings where. Thanks.

Re: CVS commit: src/sys/arch

2010-08-17 Thread David Laight
On Tue, Aug 17, 2010 at 04:08:10PM +0100, Mindaugas Rasiukevicius wrote: Unifying sizes of certain types up to 64-bits would be a good choice from engineering standpoint. Actually measuring the overhead would answer whether it is worth. Why not use a 64bit type that is the union of a 64bit

Re: CVS commit: src/sys/arch

2010-08-17 Thread Jean-Yves Migeon
On Tue, 17 Aug 2010 18:18:22 +0100, David Laight da...@l8s.co.uk wrote: Unifying sizes of certain types up to 64-bits would be a good choice from engineering standpoint. Actually measuring the overhead would answer whether it is worth. Why not use a 64bit type that is the union of a 64bit