Re-enable mmap. The problem is how uvm_fault handles page faults from
coda vnodes via container files, and executing a program caused the
same problem so disabling mmap only helped cp(1).
coda_open:
rename variables to match vnode_if.src
better comments about lock/reference state of vnodes
keep lock on container file until after VOP_OPEN, which requires locked vp
remove #if 0'd code to PNBUF_PUT
coda_link:
rename variables to match vnode_if.src
error out early if vp == dvp
check return value on vn_lock, and add comment questoining the lock
clarify lock handling, but unchanged logic
remove #if 0'd code to PNBUF_PUT
coda_rmdir:
error out early if vp == dvp
remove #if 0'd code to PNBUF_PUT
coda_grab_vnode:
add comments, and in particular question undocumented VFS_VGET semantics
coda_getpages:
question calling VOP_OPEN, which requires a locked vnode, with the
vnode we got (vop_getpages does not guarantee a locked vnode)
coda_putpages:
remove inexplicable simple_unlock(&vp->v_interlock);
add printf so we notice if this is ever called
add comment explaining that the implementation will lead to trouble,
because vnode_if.src says putpages is called with v_uobj.vmobjlock
held and is supposed to unlock it
With these changes and an uncommitted change to uvm_fault not to panic
if uvm objects are not equal, coda seems stable again.
* Add a try_set_TOOLDIR function which tries to be clever about setting
TOOLDIR if possible;
* Call try_set_TOOLDIR from rebuildmake;
* Add nobomb_getmakevar, which works like raw_getmakevar except
never bombs;
* Reimplement raw_getmakevar in terms of nobomb_getmakevar;
* Add a second arg to find_in_PATH to control the result when the
program cannot be found.
device properties - all it needs is width and height in pixels, stride in
bytes, depth in bits and the framebuffer address.
Features:
- unaccelerated fb console with colours and virtual consoles
- split into console handling and bus frontend
- so far there is only a PCI bus frontend which allows to mmap BARs belonging
to the graphics controller, others should be easy to add.
TODO:
- find an opaque way to change the palette ( probably pass a function
pointer as property ) since this would need to call some firmware interface
which is pretty much always MD
- find a clean way to mmap the framebuffer, just returning the physical
address works on macppc but not on other architectures. Problem is, that
we cannot rely on the address being a bus address - on macppc it is,
but for instance on sparc64 it's not.
got a panic in uvm_fault from ffs_write. I believe this is because cp
used mmap, the container file page was not in core, and uvm_fault
objected to the container file vnode and the coda vnode not matching.
I have long been plagued by crashes on cp from coda, and this was the
first time I got and understood a backtrace.
Clean up old comments that are no longer accurate.
Document refcounting better.
Note some questionable behaviors with XXX.
Clean up PNBUF_PUT and SAVESTART. Only do this where vnodeops(9) says
we should, and do it on error also.
In symlink, vput parent and free namebuf even in error cases.
by killing the parent process. The parent's PID is saved in $RC_PID.
* In all rc.d/* scripts that previously tried to stop the boot,
replace in-line code with "stop_boot".
* Document this.
This should fix PR 29822.
