1
0
mirror of https://git.FreeBSD.org/src.git synced 2024-11-29 08:08:37 +00:00
Commit Graph

10 Commits

Author SHA1 Message Date
Warner Losh
e9ac41698b Remove residual blank line at start of Makefile
This is a residual of the $FreeBSD$ removal.

MFC After: 3 days (though I'll just run the command on the branches)
Sponsored by: Netflix
2024-07-15 16:43:39 -06:00
Warner Losh
031beb4e23 sys: Remove $FreeBSD$: one-line sh pattern
Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/
2023-08-16 11:54:58 -06:00
Warner Losh
58aa35d429 Remove sparc64 kernel support
Remove all sparc64 specific files
Remove all sparc64 ifdefs
Removee indireeect sparc64 ifdefs
2020-02-03 17:35:11 +00:00
Enji Cooper
193d9e768b sys/modules: normalize .CURDIR-relative paths to SRCTOP
This simplifies make output/logic

Tested with:	`cd sys/modules; make ALL_MODULES=` on amd64
MFC after:	1 month
Sponsored by:	Dell EMC Isilon
2017-03-04 10:10:17 +00:00
Yoshihiro Takahashi
2b375b4edd Remove pc98 support completely.
I thank all developers and contributors for pc98.

Relnotes:	yes
2017-01-28 02:22:15 +00:00
Warner Losh
c09808d0d6 MFtbemd:
Use MACHINE_CPUARCH in preference to MACHINE_ARCH.  The former is the
source code location of the machine, the latter the binary output.  In
general, we want to use MACHINE_CPUARCH instead of MACHINE_ARCH unless
we're tesitng for a specific target.  The isn't even moot for
i386/amd64 where there's momemntum towards a MACHINE_CPUARCH == x86,
although a specific cleanup for that likely would be needed...
2010-08-23 06:13:29 +00:00
Marius Strobl
07f35f4b9a Don't build unused SBus front-ends for sun4v, don't build EBus front-ends
which are also likely to be irrelevant for sun4v (there's no SBus on sun4v
and only some EBus devices). While at it fix some style bugs according to
style.Makefile(5) where appropriate.

MFC after:	3 days
2008-05-04 14:59:25 +00:00
Marius Strobl
0222c13479 Add front-ends for the 'lebuffer' variants found on some SBus cards.
These are shared-memory variants based on Am79C90-compatible chips
that apart from the missing DMA engine are similar to the 'ledma'
variant including using a (pseudo-)bus/device for the buffer that
the actual LANCE device hangs off from. The performance of these is
close to that of the 'ledma' one, like expected at a few times the
CPU load though.
2007-01-20 12:53:30 +00:00
Marius Strobl
136eda1dc3 - 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.
2006-05-17 21:25:23 +00:00
Marius Strobl
44ac0964e9 Hook up le(4) to the build. For now it's only added to the sparc64 GENERIC
in order to support the on-board LANCE in Ultra 1 and to the MI NOTES as
it should work just fine with the AMD PCnet family of chips on all archs
but 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.
2006-01-31 22:34:13 +00:00