lwp0 uarea, curlwp, and curpcb after MMU is turned on, using
lwp0uarea variable saved during pmap_bootstrap() (or equivalent functions)
for pmap_motorola based ports. Discussed with rmind@.
this breaks abstraction. Because only lvmtools/lvmlib and device-mapper can
have knowledge about target mapping and libdevmapper only passes requests
from lvmtools to kernel and back. Bump major library and driver version.
Requested by: yamt@
* support bound kernel threads
* bind softint threads to specific virtual cpus
+ remove now-unnecessary locks from softint code
Now, if we only had MI CPU_INFO_FOREACH() .... (hi rmind ;)
Ported by FUKAUMI Naoki from OpenBSD with many modification.
No particular comments (except from me) on tech-kern@.
There are still many TODO even in MI wscons(4) API to handle this device:
* No detach function for wsdisplay(9).
Unpluging a device causes a panic. (should be trivial?)
* ioctl() for X server support is currently commented out. ("notyet")
OpenBSD allows device depedent ioctl()s and they introduced
UDLIO_DAMAGE ioctl for the damage extension ops of X servers for udl(4).
Before blindly pulling such ioctl(), probably we should discuss
how such specific operations should be handled in MI wscons(4) API.
* Screen text of wsemul tty could be mangled during large scroll ops.
All tty output operations are invoked via ttstart() with the giant
tty_lock mutex held, so we can't call cv_wait(9) to wait resources
for data xfers via usbdi(9).h, then text output is silently discarded
on resource shortage. To handle this without tty_lock reorganization,
we have to change wsdisplay(9) APIs (especially wsdisplaystart()) to
return a number of actually handled characters as OpenBSD does, but
it may require whole API changes around child rasops(9) etc.
* No MI API definition to convert mmap(9) cookie to physical address.
The conversion is required to create a cookie which will be passed to
pmap_phys_address(9) in uvm/uvm_device.c:udv_fault(). Most other
drivers use bus_dmamem_mmap(9) or bus_space_mmap(9), but udl(4) uses
kmem_alloc(9)'ed memory for bitmap data.
Furthermore, pmap(9) man page says about pmap_phys_address(9):
"This function is provided to accommodate systems which have
physical address spaces larger than can be directly addressed
by the platform's paddr_t type. The existence of this function is
highly dubious, and it is expected that this function will be
removed from the pmap API in a future release of NetBSD."
As the man page says we have already had split paddr_t and vaddr_t,
so it's time to remove such old ugly cookie and change all mmap(4)
functions (mostly in MD bus_dma(9) and bus_space(9) APIs) to return
simple physical address in paddr_t?
* We need proper device names for wsdisplay1 (and more devices).
Currently wsdisplay0 uses ttyE0 through ttyE253 (minor 0 to 253)
for screens, ttyEstat (254) for status, and ttyEcfg (255) for config.
The next wsdisplay1 will use 256 through 509 for screens, 510 for stat,
and 511 for config but what names should we use for them? ttyFxxx?
* How to handle multiple sets of wskbd/wsdisplay on a single machine.
rc.d/wscons doesn't provide method to specify wscons control devices.
There is no proper interface to specify which keyboard should be connected
to which wsdisplay, etc.
* And maybe more...
tsutsui