Strongly architect handles so we can more easily detect bogus
handles. This switches us to a full 32 bits for all handles.
Handle the case of FC disks disappearing and then reappearing-
at least at the FC transport level.
Some better and finer control of debug and non-debug printouts.
for now it uses the same monochrome overlay as OBP, otherwise it's got the
usual wsdisplay / vcons goodies
TODO:
- fill in mmap and ioctl methods so we can at least run X in monochrome
- figure out where the 24bit buffer is ( and maybe if there's an 8 bit buffer )
- see if we can do any acceleration
- find the DAC registers
and non-const types, and the kernel uses both const and non-const
PMF qualifiers and device suspensors, so change the pmf_qual_t and
device_suspensor_t typedefs from "pointers to const" to non-pointer,
non-const types.
#if NBPFILTER is no longer required in the client. This change
doesn't yet add support for loading bpf as a module, since drivers
can register before bpf is attached. However, callers of bpf can
now be modularized.
Dynamically loadable bpf could probably be done fairly easily with
coordination from the stub driver and the real driver by registering
attachments in the stub before the real driver is loaded and doing
a handoff. ... and I'm not going to ponder the depths of unload
here.
Tested with i386/MONOLITHIC, modified MONOLITHIC without bpf and rump.
dbri.c:165: warning: 'dbri_sus' declared 'static' but never defined
dbri.c: In function 'dbri_resume':
dbri.c:2188: error: 'sc' undeclared
dbri.c:2189: error: break statement not within loop or switch
XXX: sparc/dev/cgthree.c in Attic had an attachment for cgthree* at obio?
XXX: and sparc/conf/files.sparc still has an entry of nonexistent (or not yet)
XXX: sparc/dev/cgthree_obio.c. Is there any sun4m machine which requires it?
They are derived from 4.4BSD/sparc and have been there since initial import
of NetBSD/sparc in 1993, but the struct sbusdev is almost unused for years,
nothing calls sbusreset(), and all (*sd->sd_reset)() functions look bogus.
Suggested by mrg@ and martin@, and tested on SS1+ and SS20.
with possible orphaned this le at sbus one on old PROMs not using
homegrown struct sbusdev but common cfdriver_t and device_t structures.
Now nothing refers struct sbusdev registered by sbus_establish().
Tested an SBus le/esp combo card on SS1+.
not device_t parent even if sbus is grandparent of the device,
otherwise (*sd_reset)() callbacks will be called with an wrong device_t.
Even in such case, sbus_establish() looks for an sbus though device tree.
XXX: (*sd_reset)() isn't called anyway, and these stuff seems really bogus.
uebayasi