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.
the unlock parent, lock child, lock parent in the ISDOTDOT case.
Clean up and rewrite comments to match more closely current reality.
Sprinkle XXX where I'm not sure the current rules are being followed.
Reviewed by wrstuden@, who agreed that this is an improvement over the
current code, with concerns about LK_RETRY and whether the ISDOTDOT
locking is done soon enough.
