sys: Remove $FreeBSD$: one-line sh patternRemove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/
Remove sparc64 kernel supportRemove all sparc64 specific filesRemove all sparc64 ifdefsRemovee indireeect sparc64 ifdefs
sys/modules: normalize .CURDIR-relative paths to SRCTOPThis simplifies make output/logicTested with: `cd sys/modules; make ALL_MODULES=` on amd64MFC after: 1 monthSponsored by: Dell EMC Isilon
Remove pc98 support completely.I thank all developers and contributors for pc98.Relnotes: yes
MFtbemd:Use MACHINE_CPUARCH in preference to MACHINE_ARCH. The former is thesource code location of the machine, the latter the binary output. Ingeneral, we want to use MACHINE_CPUARCH instead
MFtbemd:Use MACHINE_CPUARCH in preference to MACHINE_ARCH. The former is thesource code location of the machine, the latter the binary output. Ingeneral, we want to use MACHINE_CPUARCH instead of MACHINE_ARCH unlesswe're tesitng for a specific target. The isn't even moot fori386/amd64 where there's momemntum towards a MACHINE_CPUARCH == x86,although a specific cleanup for that likely would be needed...
show more ...
Don't build unused SBus front-ends for sun4v, don't build EBus front-endswhich are also likely to be irrelevant for sun4v (there's no SBus on sun4vand only some EBus devices). While at it fix some
Don't build unused SBus front-ends for sun4v, don't build EBus front-endswhich are also likely to be irrelevant for sun4v (there's no SBus on sun4vand only some EBus devices). While at it fix some style bugs according tostyle.Makefile(5) where appropriate.MFC after: 3 days
Add front-ends for the 'lebuffer' variants found on some SBus cards.These are shared-memory variants based on Am79C90-compatible chipsthat apart from the missing DMA engine are similar to the 'ledm
Add front-ends for the 'lebuffer' variants found on some SBus cards.These are shared-memory variants based on Am79C90-compatible chipsthat apart from the missing DMA engine are similar to the 'ledma'variant including using a (pseudo-)bus/device for the buffer thatthe actual LANCE device hangs off from. The performance of these isclose to that of the 'ledma' one, like expected at a few times theCPU load though.
- Add C-bus and ISA front-ends for le(4) so it can actually replace lnc(4) on PC98 and i386. The ISA front-end supports the same non-PNP network cards as lnc(4) did and additionally a couple of P
- Add C-bus and ISA front-ends for le(4) so it can actually replace lnc(4) on PC98 and i386. The ISA front-end supports the same non-PNP network cards as lnc(4) did and additionally a couple of PNP ones. Like lnc(4), the C-bus front-end of le(4) only supports C-NET(98)S and is untested due to lack of such hardware, but given that's it's based on the respective lnc(4) and not too different from the ISA front-end it should be highly likely to work.- Remove the descriptions of le(4), which where converted from lnc(4), from sys/i386/conf/NOTES and sys/pc98/conf/NOTES as there's a common one in sys/conf/NOTES.
Hook up le(4) to the build. For now it's only added to the sparc64 GENERICin order to support the on-board LANCE in Ultra 1 and to the MI NOTES asit should work just fine with the AMD PCnet family
Hook up le(4) to the build. For now it's only added to the sparc64 GENERICin order to support the on-board LANCE in Ultra 1 and to the MI NOTES asit should work just fine with the AMD PCnet family of chips on all archsbut is not yet meant to replace lnc(4). If a kernel includes all of le(4),lnc(4) and pcn(4) precedence is given to lnc(4)/pcn(4) for now.