At this point it is highly unlikely this 1999 device still has users,
but it still comes up in the context of maxv's USB-fuzzing (and any device
could pretend to be a urio(4)), so it's best to get rid of it.
Renamed all major entries to obsolete, as was done in previous removals.
This still requires an update to sanitizers, but they're located in
"external", perhaps it should be first committed upstream?
Proposed on tech-kern a month ago.
- If the config had both an le@pci and a pcn, simply remove le@pci
(pcn would match at a higher priority anyway).
- If the config had le@pci enabled, but no pcn, change le@pci to pcn.
- If the config had le@pci commented out, but no pcn, change le@pci
to pcn and leave it commented out.
The pcn driver supports more chips than le@pci and does DMA directly
to/from mbufs rather than memory copies.
On ports without a GENERIC kernel config enable in individul files, e.g evbmips.
Omit on:
atari, dreamcast, emips, epoc32, evbppc/VIRTEX*, ia64, luna68x, mvme68k,
mvmeppc, playstation2, riscv, sun2, sun3, x68k, zaurus due to resource
constraints or port infancy.
- Every driver that was removed and whose number hasn't already been
reused is now listed with a commented-out "obsolete" line.
- The format of these has been systematized. Future format changes can
probably be safely done with a script.
- This does not include a few cases of assignments that only lasted a
couple days, or stuff from before major reorgs. Some of these may
be included nonetheless, because there was a lot of ground to cover
and therefore not a lot of time to dig into history in detail.
Note that the obsolete listings do not mean the major numbers can
never be reused; that's up to portmasters and/or core. It does mean
that they won't be reused by accident, however, which in some cases
(depending on the driver, how widely used it was, its family of device
nodes, their default permissions, etc.) can be quite dangerous.
Note that some of the things now explicitly listed as obsolete are
really ancient history. My scan went back as far as when the majors
files were added. (But not before that.)
also move BLKDEV_IOSIZE, MAXPHYS, but allow override since some ports
have different value (powerpc uses NBPG for BLKDEV_IOSIZE, sun2/sun3
have lower MAXPHYS)
is of poor quality, and is now an obstacle to MP-ification. It was removed
ten years ago from FreeBSD for the same reason.
This retires a big user of the mbuf API, and will ease maintenance of the
kernel.
This change:
* Removes "options PERFCTRS", the associated includes, and the associated
ifdefs. In doing so, it removes several XXXSMPs in the MI code, which is
good.
* Removes the PMC code of ARM XSCALE.
* Removes all the pmc.h files. They were all empty, except for ARM XSCALE.
* Reorders the x86 PMC code not to rely on the legacy pmc.h file. The
definitions are put in sysarch.h.
* Removes the kern/sys_pmc.c file, and along with it, the sys_pmc_control
and sys_pmc_get_info syscalls. They are marked as OBSOL in kern,
netbsd32 and rump.
* Removes the pmc_evid_t and pmc_ctr_t types.
* Removes all the associated man pages. The sets are marked as obsolete.
We now have 2 variables automatically set in elf_machdep.h:
ARCH_ELFSIZE: the size for userland binaries
KERN_ELFSIZE: the size for the kernel binaries
DB_ELFSIZE has been deleted and KERN_ELFSIZE should have always the
same values DB_ELFSIZE used to have.
In sys/exec_elf.h, if ELFSIZE is not set, it is set to KERN_ELFSIZE
for the kernel and ARCH_ELFSIZE for userland. These defaults should
eliminate the need for most manual ELFSIZE setting.
- new series of files that are useful for saying "i want everything
since netbsd 1.4", etc.
- use the fact COMPAT_* options have future dependancies to remove
many redundant options.
removes about 3000 lines total across kernel configuration files.
tested about 30 random kernels in the changed list.
- Add PCI Extended Configuration Space support into x86.
- Check register offset of pci_conf_read() in MD part. It returns (pcireg_t)-1
if it isn't accessible.
- Decode Extended Capability in PCI Extended Configuration Space.
Currently the following extended capabilities are decoded:
- Advanced Error Reporting
- Virtual Channel
- Device Serial Number
- Power Budgeting
- Root Complex Link Declaration
- Root Complex Event Collector Association
- Access Control Services
- Alternative Routing-ID Interpretation
- Address Translation Services
- Single Root IO Virtualization
- Page Request
- TPH Requester
- Latency Tolerance Reporting
- Secondary PCI Express
- Process Address Space ID
- LN Requester
- L1 PM Substates
The following extended capabilities are not decoded yet:
- Root Complex Internal Link Control
- Multi-Function Virtual Channel
- RCRB Header
- Vendor Unique
- Configuration Access Correction
- Multiple Root IO Virtualization
- Multicast
- Resizable BAR
- Dynamic Power Allocation
- Protocol Multiplexing
- Downstream Port Containment
- Precision Time Management
- M-PCIe
- Function Reading Status Queueing
- Readiness Time Reporting
- Designated Vendor-Specific
config(1)/config(5) can't handle module dependency correctly at this
moment.
(This is another proof that shared file definition (`file xxx.c a|b')
is a bad idea.)
jdolecek