to all GENERIC-like kernel config files where SYSV* options were already
present (commented out if the SYSV* options are commented out).
Fix lib/25897 and lib/25898.
drivers that attach to it. This allows for other host interface chips
that use the same keyboards and mice, such as the ones in the ARM
IOMD20, ARM7500, and SA-1111. The PC-compatible driver is still
called pckbc(4), and the new abstraction layer is "pckbport", so the
child devices have moved from sys/dev/pckbc to sys/dev/pckbport, which
also contains some code shared between all host controllers. To avoid
incompatibility, pckbdreg.h is still installed in
/usr/include/dev/pckbc.
In theory, this shouldn't cause any behavioural changes in the drivers
concerned. Thy just use rather more function pointers than before. Tested
on i386 and (with a new host driver) acorn32. Compiled on several other
affected architectures.
* lpt device is defined in MI place (dev/ppbus/files.ppbus), dev/ic/lpt.c
is included there too; dev/ic/lpt.c is not included if ppbus is
configured or if there is alternative platform lpt (like for pc532)
* g/c MD lpt definitions and custom puc/upc attachments,
glue moved to conf/files and dev/pci/files.pci respectively; remove
device lpt definition from dev/isa/files.isa
* add ppbus parport attribute, atppc device attachments, adjust plip and lpt
glue
files for machines I know to have genuine PCI slots. As sent to tech-kern
for feedback in December 2003. Based on feedback, opencrypto is commented
out in the macppc GENERIC (due to absense of GENERIC_SOFTINT support),
and added to the sparc64 config (sys/arch/sparc64/conf/GENERIC32).
1. ABLE sets the l1pt to use domain 3 for it's entries (no idea why) so to
cover all bases when setting the domain before the change to the new L1pt
become a client of all domains.
2. It seems that we setup the kernel entries without any access permission.
(note not sure that this isn't a bug) And rely on the control bits
containing either ROM or SYST enable. which allows access to pages without
access permissions set. We actually enable SYST when we do the full detect
of the CPU, but we don't detect the CPU till after the L1pt switch, which
we never make it past. Fix this by explicitly enabling the SYST bit in the
control register. rather than relying on the firmware to have dont the right
thing.
esiop has been tested enouth now.
esiop not added to INSTALL kernels because of possible space constraint.
siop should be able to drive all adapters supported by esiop.
Also in the ARM32_PMAP_NEW case, reclaim the USPACE-bytes of wasted space
at the top of the user address that hasn't been needed for a very very
long time.
drochner