Pull up following revision(s) (requested by dsl in ticket #305):
	sys/sys/sysctl.h: patch

Define CTLTYPE_LONG in preparation for more pullups.
Pull up following revision(s) (requested by dsl in ticket #306):
	sys/kern/vfs_bio.c: revision 1.238
	sys/dev/bluetooth/bcsp.c: revision 1.21
	sys/dev/acpi/asus_acpi.c: revision 1.24
	sys/miscfs/syncfs/sync_subr.c: revision 1.48
Some calls to sysctl_createv() have mismatches betwwen the data type
and the CTLTYPE_xxx flags.
Fixes bugs in sys/dev/acpi/asus_acpi.c sys/dev/bluetooth/bcsp.c
  sys/kern/vfs_bio.c sys/miscfs/syncfs/sync_subr.c
(mostly passing the address of a uint64_t when typed as CTLTYPE_INT).
The vm.bufmem_lowater (etc) sysctls needs to be processed with a
  64bit temporary value on 64bit systems.
Fixes PR kern/46536.
Pull up following revision(s) (requested by dsl in ticket #307):
	sys/kern/vfs_bio.c: revision 1.239
Use separate temporaries for the 'int' percentage and the 'long'
  water marks.
Previous paniced on sparc64 due to a misaligned copy.
Pull up following revision(s) (requested by martin in ticket #310):
	sys/kern/kern_proc.c: revision 1.184
	lib/libkvm/kvm_proc.c: revision 1.89
Measure kinfo_proc2::p_vm_vsize in pages, as it was always documented.
This value seems to never have been used anywhere.
This makes it consistent with it's cousin p_vm_msize (which is in pages as
well and has several uses).
Pull up following revision(s) (requested by abs in ticket #311):
	sys/arch/netwinder/conf/GENERIC: revision 1.112
	sys/arch/i386/conf/GENERIC: revision 1.1074
	sys/arch/atari/conf/MILAN.in: revision 1.26
	sys/arch/zaurus/conf/GENERIC: revision 1.54
	sys/arch/shark/conf/GENERIC: revision 1.101
	sys/arch/hpcmips/conf/MPC303: revision 1.60
	sys/arch/i386/conf/XEN3_DOM0: revision 1.67
	sys/arch/evbarm/conf/MPCSA_GENERIC: revision 1.29
	sys/arch/vax/conf/GENERIC: revision 1.181
	sys/arch/sparc/conf/KRUPS: revision 1.59
	sys/arch/evbarm/conf/BEAGLEBOARD: revision 1.27
	sys/arch/i386/conf/INSTALL_FLOPPY: revision 1.16
	sys/arch/prep/conf/GENERIC: revision 1.163
	sys/arch/hpcmips/conf/GENERIC: revision 1.216
	sys/arch/sparc/conf/TADPOLE3GX: revision 1.56
	sys/arch/shark/conf/INSTALL: revision 1.50
	sys/arch/next68k/conf/GENERIC: revision 1.127
	sys/arch/evbppc/conf/VIRTEX_GSRD2: revision 1.16
	sys/arch/evbppc/conf/VIRTEX_DFC: revision 1.17
	sys/arch/evbppc/conf/EXPLORA451: revision 1.48
	sys/arch/bebox/conf/INSTALL: revision 1.54
	sys/arch/next68k/conf/SLAB: revision 1.46
	sys/arch/i386/conf/GENERIC_TINY: revision 1.132
	sys/arch/bebox/conf/GENERIC: revision 1.131
	sys/arch/amd64/conf/XEN3_DOM0: revision 1.84
	sys/arch/amd64/conf/GENERIC: revision 1.356
	sys/arch/evbarm/conf/MMNET_GENERIC: revision 1.6
	share/man/man4/wscons.4: revision 1.31
	sys/arch/hpcmips/conf/TX3912: revision 1.79
	sys/arch/evbarm/conf/ARMADILLO9: revision 1.35
	sys/arch/hpcsh/conf/GENERIC: revision 1.97
	sys/arch/i386/conf/ALL: revision 1.339
	sys/arch/hpcmips/conf/TX3922: revision 1.93
	sys/arch/cats/conf/INSTALL: revision 1.82
	sys/arch/sparc64/conf/GENERIC: revision 1.151
	sys/arch/i386/conf/INSTALL_TINY: revision 1.135
	sys/arch/evbppc/conf/VIRTEX_GSRD1: revision 1.15
	sys/arch/evbarm/conf/TS7200: revision 1.49
	sys/arch/hpcmips/conf/VR41XX: revision 1.55
	sys/arch/hp700/conf/GENERIC: revision 1.115
	sys/arch/cats/conf/GENERIC: revision 1.140
Mention wsconscfg(8) needs WSDISPLAY_COMPAT_USL
If a port is going to have wscons for virtual terminals then it really make=
s
sense to enable WSDISPLAY_COMPAT_USL so the system can switch between the
virtual terminals...
Adjust the WSDISPLAY_COMPAT_USL comment to mention wsconscfg, to at least
give a hint that its not just for third party compat. No functional change.
Tickets 305-307,310,311
Pull up following revision(s) (requested by abs in ticket #312):
	sys/net/bpf.h: revision 1.59
add {__BEGIN,__END}_DECLS
Pull up following revision(s) (requested by sborrill in ticket #313):
	sys/arch/xen/xenbus/xenbus_probe.c: revision 1.36
	sys/arch/xen/xenbus/xenbus_probe.c: revision 1.37
Sort vif and vbd device IDs numerically so that attach order does not depend
on the order they are passed in through xenstore. While this works for
hand-crafted Xen configuration files, it does not work for XenServer, XCP or
EC2 instances. This means that adding an extra virtual disk can make the
domU unbootable.
ID is actually based on the Linux device major/minor so this approach isn't
entirely correct (for instance, you can specify devices to be non-contiguous
which doesn't fit too well with our autoconf approach), but it works as a
first approximation.
Tested by me on XenServer and riz@ on EC2. OK bouyer@
Fix problem where devices with ID 0 were skipped as invalid as it didn't
distinguish between numerical zero and invalid numeric string.
Tickets 312,313