with the also-experimental ioconf keyword. pseudo-root allows to
specify a root at any point in the device tree without having
attachments from the actual root.
For example, instead of having a config file like this:
mainbus0 at root
bus_a? at mainbus0
bus_b? at bus_a*
device7 at bus_b?
You can have one like this:
pseudo-root bus_b*
device7 at bus_b?
This will produce the relevant ioconf.c glue for device number 7
only instead of the whole 9 yards from root. Perhaps needless to
say, this can be used to generate snippets of config glue for
modules and, let's not deny that my main motivation for doing this,
rump components.
This is part 2/3 of my modifications to config (the last part is
autogenerating source file lists and component Makefiles).
No strong objection from cube (after a little pressuring ;), but
like he said, the implementation will most likely need some more
tweaking and may not work correctly under all pseudo-root uses yet.
- blast_dcache() becomes sp_blast_dcache(dcache_size, dcache_line_size)
- new smp_blast_dcache(sparc64_cpuset_t) that blasts the D$ on this cpuset
- sparc64_ipi_blast_dcache() to support the above
- in pmap_remove_all(), when freeing mmu contexts for this pmap, mark
the set of cpus to blast the d$ on as well and convert the
blast_dcache() call into smp_blast_dcache() on the cpus who ran this
pmap, or, sp_blast_dcache(dcache_size, dcache_line_size)
- convert the remaining blast_dcache() in machdep.c to sp_blast_dcache()
- in pmap_destroy()/pmap_remove_all() take the pmap_lock() always since
we assert it is held always.
with these changes, NFS builds on the U60 seem to be stable now, and
the USIII machines also can often complete a single build.sh run now,
diskful or diskless.
reviewed by mlelstv and partially by martin, tested by martin and myself,
with some ideas from chuq as well.
kernel and provides the same device on the host with pud(4). I
can succesfully talk to my u3g device using tip(1) against the
server's devices. Some characters are lost here and there, though
(probably a problem with interrupt pipes in ugenhc). Once that
issues is solved, there is no reason why e.g. pppd (chat) could
not be used against the server.
Now, why would anyone want to do this instead of using the kernel
driver directly? Well, for one, on my laptop I run netbsd-5 which
doesn't have a u3g driver which supports the u3g hardware I have.
As anyone with half an eye can see, this is quite copypasted from
umserv and there is plenty of opportunity for uncopypasting for
the eager vi-wielder.
