is shared with another process (as can happen if vfork is being used),
then that other process will end up not having a page 0, which is bad
news indeed, since then there is no way back into the kernel.
Found this using a multi-ice box, so they are useful after all!
This seems to fix pr port-arm32/11921 and (possibly) kern/9859.
broken hueristic to determine memory vs. i/o (one should never make
an assumption that the bus_space_tag_t is a pointer, as this code
did).
- Fix the "can't map registers" error message.
- Garbage-collect some code that is not relevant to the GEM (which
was already #if 0'd out).
- Cluster all the SPARC-specific code into one place (will be
replaced with Properties once that is fleshed out).
- fix bug where the 'clear' flag was set outside of main loop, so
"dump,uchg,arch" on a file with flags would clear all the bits
(because "dump" sets 'clear'). noted in FreeBSD PR 10071, and fix
obtained from FreeBSD.
- enforce right-most priority on arguments by clearing the appropriate
bit in the opposite set; if a string of "nouchg,uchg" is given,
chflags(8) would clear uchg because it applies the "set" bits before
clearing the "clear" bits. now, "uchg" sets UF_IMMUTABLE in setp
and also resets it in clrp, solving this problem
- constify second arg (the `default' arg)
string, if present, will override the second argument (which may be the
path/kernel being loaded). This will provide a way to netboot the kernel
and allow the root device be set to a disk partition.
line parameters, and device_register() to try to match the boot device. Works
on a Challenge S (and similar machines), but will need more work for other
SCSI adapters.
and RC7500 from the old arch/arm32 that is gonna be deleted in its whole
soon.
IMPORTANT for RC7500 ... this also removes all RC7500 support .... its a
big pitty but was virtually unsupported allready for a few years and noone
had one... if someone wants to make RC7500 or decendants support undo this
removal and start from here.
arch/arm/iomd/* .... the RC7500 isnt really an iomd/vidc machine but has
different video/audio chip and was kind of hardwired/hacked into the other
chip drivers.
If __PCI_DEV_FUNCORDER is defined, don't do the song-and-dance to check if
a device is multi-function; machdep code is going to tell us exactly which
functions to probe.
Note this required changing how pci_func_devorder() works in the
sparc64 PCI machdep code; now the "curnode" is assumed to point
to the bus, rather than some function (typically 0) on the device,
just as pci_bus_devorder() makes that assumption.
All this should allow the PCI code to actually locate the second
HME device on a Sun Netra t1, which is at 3,1 -- previously, the
PCI code would have missed it because there is no device at 3,0.
(Sun deserves a brick to the head for this one -- this seems clearly
out of line with the PCI spec.)
rearnsha