kernels with 'options I586_CPU.'
The declaration for pentium_mhz is hidden inside an #ifdef I586_CPU,
but machdep.c refers to it whether I586_CPU is defined or not. This
temporary hack puts the offending code inside an #ifdef I586_CPU as
well so that a kernel without it will successfully compile.
I must emphasize the word 'temporary:' somebody needs to seriously
beat on the identifycpu() function with an #ifdef stick so that
I386_CPU, I486_CPU and I586_CPU will do the right things.
Dropping into the debugger when a break comes down the serial line is a
>MISFEATURE (1st class)< and has been put under it's own #ifdef. This
should be a magic sequence of chars instead.
For those where it was easy, drivers were also fixed to call
dev_attach() during probe rather than attach (in keeping with the
new design articulated in a mail message five months ago). For
a few that were really easy, correct state tracking was added as well.
The `fd' driver was fixed to correctly fill in the description.
The CPU identify code was fixed to attach a `cpu' device. The code
was also massively reordered to fill in cpu_model with somethingremotely
resembling what identifycpu() prints out. A few bytes saved by using
%b to format the features list rather than lots of ifs.
like "3DBorder" and "[". (NB, the "3DBorder" problem has actually
been intention, it allowed for weird section names like "3xyzzy". We
don't have them, either.)
(Partially) Submitted by: taob@gate.sinica.edu.tw (Brian Tao)
link stage fell over for any program that attempted to use rexec().
Ruserpass() remains undocumented; i could not find any documentation
for it on other systems.
Also added a BUGS section to the man page, stating that this function
constitutes a potential security hole (as well as the underlying
"exec" service).
Submitted by: rgrimes
Originally submitted by: agc@uts.amdahl.com (Alistair G. Crooks)
Obtained from: netbsd-bugs@NetBSD.ORG
Fix PR 303: msdosfs: moving a file into another directory causes panic.
" ... the code that does the rename already has the denode
locked when msdosfs_hashins() gets called, resulting in the panic
when the routine attempts to lock the denode again.
...
The attached patch changes the msdosfs_hashins() routine to not lock the
denode. The caller is now resposible for obtaining the lock instead
of having msdosfs_hashins() do it for them."
don't lock the vnode - it doesn't appear to ever be necessary for VCHR
vnode/inodes. This fixes a bug introduced in the previous commit that
caused tty timestamps to act strange (causing 'w' and 'finger' to show
the tty wasn't idle when it may have been for hours).
