one. Fixes a panic reported by njoly@ in private Email
2. Acquire the device before checking whether or not the get_limits
routine exists.
XXX There's still a bug in here somewhere that prevents setting of
XXX limit values after using 'envstat -S'
paddr_t has limited interest in userland, and should only be used by specific
code like kvm(3) (for VA => PA translations). To support non PAE and PAE
kernels simultaneously in kvm(3), promote paddr_t to 64 bits.
No objection on current-users@. See also:
http://mail-index.netbsd.org/current-users/2010/09/07/msg014249.html
Kernel remains untouched by this change. In-kernel 64 bits for paddr_t is for
a future commit (Yes, I do not forget about that :) )
-int _kvm_kvatop(kvm_t *, u_long, u_long *);
-off_t _kvm_pa2off(kvm_t *, u_long);
+int _kvm_kvatop(kvm_t *, vaddr_t, paddr_t *);
+off_t _kvm_pa2off(kvm_t *, paddr_t);
Basically, use vaddr_t for VA and paddr_t for PA. In addition, for variables
representing addresses, use paddr_t or vaddr_t, depending on the context.
For most arches, vaddr_t and paddr_t are equivalent to unsigned long. However,
the change was needed for exotic situations, like i386 PAE, were unsigned long
is not suitable for PA which are 64 bits long. As this required a complete
change of the function prototypes, all arches had to be adapted accordingly.
Core files from before this commit should still work with the new code; I did
not see any direct dependency between core's structure and kvatop/pa2off.
The change was compile tested for all arches, as it impacts all of them.
See also:
http://mail-index.netbsd.org/current-users/2010/09/07/msg014249.html
SOCK_DGRAM, we can send many pages at once without hitting any bug
- when creating a file, it is open for FUSE, but not for the kernel.
If the kernel does not do a subsequent open, we have a leak. We fight
against this by trying to close such file that the kernel left unopen
for some time.
- some code refactoring to make message exchange debug easier (more to come)
