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)
Mortals do not need to be able to generate PCI Configuration Space
read transactions, which are not entirely without side effect, as
reported in PR#16300.
64 bit integers (eg, sparc). the problem was that the new 64 bit
element on the end was used for the offsetof() (aka size) for the old
structure, but this includes the padding required, thus the ioctl number
was set wrongly.
move all the supporting code for this inside COMPAT_50, with some renaming
to suit, and kill all the external definitions related to it.
tested on i386, amd64 and sparc.
which grew since netbsd 5.0 (hi christos!)
fix a few issues/problems:
- the COMPAT_30 code wasn't used since opt_compat_netbsd.h wasn't included
- move 'struct vnd_ouser' (for COMPAT_30) into vnd.c itself, and call it
'struct vnd_user30'
- same for VNDIOOCGET -> VNDIOCGET30
now 'vnconfig -l' works on -current with a netbsd-5 binary, using i386.
XXX: there is still a potential problem with the old VNDIOOCSET and
VNDIOOCCLR macros on some platforms like sparc. there is padding
between the old vnd_osize member and the new vnd_size member on
platforms that want 64 bit values 64 bit aligned, but are 32 bit
otherwise (like sparc.) 64 bit systems already end up with this
member 64 bit aligned, and should be fine.
this most likely results in the old ioctl numbers being wrong and
the code won't match/run ever (ENOTTY.)
options EXEC_ELF32, EXEC_SCRIPTS, and CPU_IN_CKSUM for md cpu_in_cksum.c
- make all m68k ports include common arch/m68k/conf/std.m68k
from MD std.${MACHINE}
Based on sys/netinet/cpu_in_cksum.c but just modified
to use traditional MD m68k/oc_cksum.s.
Makes ~5% improvements of ttcp(1) xfer rates on ATARI TT030 + SMC_TT.
Analyzed in PR port-mips/43882, but applied slightly different patch.
Also put some changes for readability.
Note netbsd-5 doesn't use this MD version but netbsd-4 needs a pullup.
(though it's unclear if it's really faster even on modern aggressive gcc4)
