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,
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.
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
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) {
- /*
-
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
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) {
- /*
-
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
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
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
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
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.
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
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
13 matches
Mail list logo