You could turn this off by debug.mpsafenet=0 for full network
stack or via debug.{cp|cx|ctau}.mpsafenet for cp(4), cx(4) and
ctau(4) accordingly.
MFC after: 10 days
- Removed kttcp_sosend() and kttcp_soreceive() in favor of using
sosend() / soreceive() with UIO_NOCOPY. The locking changes in the
socket layer make merging the kttcp_so* and the so* routines a real
pain. It was a lot easier to just use the integrated routines.
- Eliminated KTTCP_MAX_XMIT restrictions on send and receive sizes
because I encountered no problems with streams larger than MAX_INT.
MAX_INT bytes is only good for a few seconds at 4Gb/sec ;)
- Removed Giant from send / recv routines.
- Fixed character device protos, cdevsw init, etc, to work in 5.x /
6.x
Reviewed by: sam
MFC after: 1 week
nice value above 0, set it to 0 so that it may proceed with haste.
This is especially important on ULE, where adjusting the priority
does not guarantee that a thread will be granted a greater time slice.
This allows LCP ECHOs to be enabled independently of LQR reports.
Note: This introduces a change in the default behaviour (search for lqr and
echo in the man page). I'll update UPDATING to reflect this.
PR: 74821
Now only things that are different between us and NetBSD show up.
Means that these files are more of NetBSD style in some places but
since thay are NetBSD files, um, that's ok.
Obtained from: NetBSD
MFC after: 1 week
do things correctly from an aliasing perspective. Put the
vop_generic_args element as the first element for all the vop_*_args
and adjust the code to take the address of that instead of the
structure.
OK'd based on a vague description by: phk
specifically, vm_pgmoveco():
1. If vm_pgmoveco() sleeps on a busy page, it must redo the look up
because the page may have been freed.
2. If the receive buffer is copy-on-write due to, for example, a fork,
then although the first vm object in the shadow chain may not contain
a page there may still be one from a backing object that is mapped.
Thus, a pmap_remove() is required for the new page rather than the
backing object's page to been seen by the application.
Also, add some comments to vm_pgmoveco() and update some assertions.
Tested by: ken@
pointer to eliminate the hundreds of warnings that we have in tree at
the moment.
# Chances are good that all the struct vop_*_args should have, as its
# first element, the struct vop_generic_args, and when necessary to
# reference it, we just take its address rather than going through
# this double case.
When make flags are passed to make in the environment, the string is
chopped up in an (argc,argv) vector. This happens in brk_string() and
the chopped up string is stored in static buffer. When this includes
something like "-V BINMAKE", then a pointer into the static buffer is
put on the variables list for evaluation later. However, brk_string()
is used for more than just chopping up the MAKEFLAGS env. variable, so
it's very likely that the static buffer is clobbered. In fact, this is
exactly what happens.
The result is that _MAKEOBJDIRPREFIX gets assigned whatever garbage
the child make happens to emit, causing the test to fail. Like this:
pluto2% cd /usr/src
pluto2% make -V BINMAKE
"/q/6.x/src/Makefile", line 94: MAKEOBJDIRPREFIX can only be set in environment, not as a global (in /etc/make.conf) or command-line variable.
pluto2% make -dv -V BINMAKE | & grep _MAKEOBJDIRPREFIX
Global:_MAKEOBJDIRPREFIX = }
The fix is to not use MAKEFLAGS for this, but simple pass the flags
as arguments. Ideally make(1) should be fixed but that's beyond the
scope of my attention span.
This fixes release.
the ISA and CBUS (called isa on pc98) attachments. Eliminate all PC98
ifdefs in the process (the driver in pc98/pc98/mse.c was a copy of the one
in i386/isa/mse.c with PC98 ifdefs). Create a module for this driver.
I've tested this my PC-9821RaS40 with moused. I've not tested this on i386
because I have no InPort cards, or similar such things. NEC standardized
on bus mice very early, long before ps/2 mice ports apeared, so all PC-98
machines supported by FreeBSD/pc98 have bus mice, I believe.
Reviewed by: nyan-san
