History log of /freebsd/sys/conf/kmod.mk (Results 251 – 275 of 777)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 552311f4 17-Jul-2013 Xin LI <delphij@FreeBSD.org>

IFC @253398


# 2565edc4 09-Jul-2013 Andriy Gapon <avg@FreeBSD.org>

amd64: use -mno-omit-leaf-frame-pointer in addition to -fno-omit-frame-pointer

... in kernel builds. This is to make behavior of clang consistent with
behavior of gcc.

MFC after: 2 weeks


# cfe30d02 19-Jun-2013 Gleb Smirnoff <glebius@FreeBSD.org>

Merge fresh head.


Revision tags: release/8.4.0, release/9.1.0
# 300675f6 27-Nov-2012 Alexander Motin <mav@FreeBSD.org>

MFC


# e477abf7 27-Nov-2012 Alexander Motin <mav@FreeBSD.org>

MFC @ r241285


# a10c6f55 11-Nov-2012 Neel Natu <neel@FreeBSD.org>

IFC @ r242684


# 23090366 04-Nov-2012 Simon J. Gerraty <sjg@FreeBSD.org>

Sync from head


# d6b3aaf8 16-Oct-2012 Oleksandr Tymoshenko <gonzo@FreeBSD.org>

Split sdhci driver in two parts: sdhci and sdhci_pci.
sdchi encapsulates a generic SD Host Controller logic that relies on
actual hardware driver for register access.

sdhci_pci implements driver for

Split sdhci driver in two parts: sdhci and sdhci_pci.
sdchi encapsulates a generic SD Host Controller logic that relies on
actual hardware driver for register access.

sdhci_pci implements driver for PCI SDHC controllers using new SDHCI
interface

No kernel config modifications are required, but if you load sdhc
as a module you must switch to sdhci_pci instead.

show more ...


# 9215d178 13-Sep-2012 Brooks Davis <brooks@FreeBSD.org>

Introduce a new make variable COMPILER_TYPE that specifies what
type of compiler is being used (currently clang or gcc). COMPILER_TYPE
is set in the new bsd.compiler.mk file based on the value of th

Introduce a new make variable COMPILER_TYPE that specifies what
type of compiler is being used (currently clang or gcc). COMPILER_TYPE
is set in the new bsd.compiler.mk file based on the value of the CC
variable or, should it prove informative, by running ${CC} --version
and examining the output.

To avoid negative performance impacts in the default case and correct
value for COMPILER_TYPE type is determined and passed in the environment
of submake instances while building world.

Replace adhoc attempts at determining the compiler type by examining
CC or MK_CLANG_IS_CC with checks of COMPILER_TYPE. This eliminates
bootstrapping complications when first setting WITH_CLANG_IS_CC.

Sponsored by: DARPA, AFRL
Reviewed by: Yamaya Takashi <yamayan@kbh.biglobe.ne.jp>, imp, linimon
(with some modifications post review)
MFC after: 2 weeks

show more ...


# 24bf3585 04-Sep-2012 Gleb Smirnoff <glebius@FreeBSD.org>

Merge head r233826 through r240095.


# 7750ad47 22-Aug-2012 Marcel Moolenaar <marcel@FreeBSD.org>

Sync FreeBSD's bmake branch with Juniper's internal bmake branch.

Requested by: Simon Gerraty <sjg@juniper.net>


# 4da573d9 15-Aug-2012 Oleksandr Tymoshenko <gonzo@FreeBSD.org>

Merging of projects/armv6, part 3

r238211:
Support TARGET_ARCH=armv6 and TARGET_ARCH=armv6eb

This adds a new TARGET_ARCH for building on ARM
processors that support the ARMv6K multiprocessor
extens

Merging of projects/armv6, part 3

r238211:
Support TARGET_ARCH=armv6 and TARGET_ARCH=armv6eb

This adds a new TARGET_ARCH for building on ARM
processors that support the ARMv6K multiprocessor
extensions. In particular, these processors have
better support for TLS and mutex operations.

This mostly touches a lot of Makefiles to extend
existing patterns for inferring CPUARCH from ARCH.
It also configures:
* GCC to default to arm1176jz-s
* GCC to predefine __FreeBSD_ARCH_armv6__
* gas to default to ARM_ARCH_V6K
* uname -p to return 'armv6'
* make so that MACHINE_ARCH defaults to 'armv6'
It also changes a number of headers to use
the compiler __ARM_ARCH_XXX__ macros to configure
processor-specific support routines.

Submitted by: Tim Kientzle <kientzle@freebsd.org>

show more ...


# de720122 15-Jul-2012 Gleb Smirnoff <glebius@FreeBSD.org>

Merge head r236710 through r238467.


# 6cf87ec8 13-Jul-2012 Xin LI <delphij@FreeBSD.org>

IFC @238412.


# b652778e 11-Jul-2012 Peter Grehan <grehan@FreeBSD.org>

IFC @ r238370


# cd95660f 03-Jul-2012 David E. O'Brien <obrien@FreeBSD.org>

Revert r222186 per instructions for FreeBSD 10.
(a 10-CURRENT share/mk is already required to build a 10-CURRENT kernel
on 9-STABLE)


# 31ccd489 28-May-2012 Gleb Smirnoff <glebius@FreeBSD.org>

Merge head r233826 through r236168.


# 6a068746 15-May-2012 Alexander Motin <mav@FreeBSD.org>

MFC


# 4574da7f 01-May-2012 Adrian Chadd <adrian@FreeBSD.org>

Bring over the first part of the etherswitch framework - an MDIO bus and
MDIO/MII rendezvous proxy.

* Add an 'mdio' bus, which is the "IO" side of an MII bus (but by design
can be anything which i

Bring over the first part of the etherswitch framework - an MDIO bus and
MDIO/MII rendezvous proxy.

* Add an 'mdio' bus, which is the "IO" side of an MII bus (but by design
can be anything which implements the underlying register access API.)
* Add 'miiproxy' and 'mdioproxy', which provides a rendezvous mechanism
for MII busses to appear hanging off arbitrary busses (ie, that aren't
necessarily a traditional looking MII bus.)

MII busses can now hang off anything that implements an mdiobus.

For the AR71xx SoC, there's one MDIO bus but two MII busses. So to
properly support two or more real PHYs, this can be done:

# arge0 MDIO bus - there's no arge1 MDIO bus for AR71xx
hint.argemdio.0.at="nexus0"
hint.argemdio.0.maddr=0x19000000
hint.argemdio.0.msize=0x1000
hint.argemdio.0.order=0

# Create two mdioproxy instances
hint.mdioproxy.0.at="mdio0"
hint.mdioproxy.1.at="mdio0"

# .. and with a follow-up patch
hint.arge.0.mdio=mdioproxy0
hint.arge.1.mdio=mdioproxy0

TODO:

* Do a sweep or two and add appropriate locking in mdio/mdioproxy/miiproxy.

Submitted by: Stefan Bethke <stb@lassitu.de>
Reviewed by: ray

show more ...


# 38f1b189 26-Apr-2012 Peter Grehan <grehan@FreeBSD.org>

IFC @ r234692

sys/amd64/include/cpufunc.h
sys/amd64/include/fpu.h
sys/amd64/amd64/fpu.c
sys/amd64/vmm/vmm.c

- Add API to allow vmm FPU state init/save/restore.

FP stuff discussed with: kib


Revision tags: release/8.3.0_cvs, release/8.3.0
# 8833b15f 03-Apr-2012 Gleb Smirnoff <glebius@FreeBSD.org>

Merge head r232686 through r233825 into projects/pf/head.


# 84db023e 29-Mar-2012 Juli Mallett <jmallett@FreeBSD.org>

Assume a big-endian default on MIPS and drop the "eb" suffix from MACHINE_ARCH.
This makes our naming scheme more closely match other systems and the
expectations of much third-party software. MIPS

Assume a big-endian default on MIPS and drop the "eb" suffix from MACHINE_ARCH.
This makes our naming scheme more closely match other systems and the
expectations of much third-party software. MIPS builds which are little-endian
should require and exhibit no changes. Big-endian TARGET_ARCHes must be
changed:
From: To:
mipseb mips
mipsn32eb mipsn32
mips64eb mips64

An entry has been added to UPDATING and some foot-shooting protection (complete
with warnings which should become errors in the near future) to the top-level
base system Makefile.

show more ...


# 867099fa 08-Mar-2012 Gleb Smirnoff <glebius@FreeBSD.org>

Merge head up to r232685 to projects/pf/head.


# 2651e350 04-Mar-2012 Dimitry Andric <dim@FreeBSD.org>

Revert r232473. I have been convinced by Doug Barton and Bjoern Zeeb
that it is better to error out when people attempt to build using the
wrong bsd.*.mk files, than to silently ignore the problem.

Revert r232473. I have been convinced by Doug Barton and Bjoern Zeeb
that it is better to error out when people attempt to build using the
wrong bsd.*.mk files, than to silently ignore the problem.

This means, that after this commit, if you want to build kernel modules
by hand (or via a port) from a head source tree, you *must* make sure
the files in /usr/share/mk are in sync with that tree. If that isn't
possible, for example when you are running on an older FreeBSD branch,
you can:

- Run "make buildenv" from your head source tree, to have the correct
environment setup. (It's advisable to have run "make buildworld", or
at a minimum "make toolchain" first.)
- Alternatively, set MAKESYSPATH to the share/mk directory under your
head source tree. If your build tools are too old, other problems may
still occur.
- Alternatively, use "make -m" and specify the share/mk directory under
your head source tree. Again, build tools that are too old may still
result in trouble.

MFC after: 2 weeks

show more ...


# 2677e7fe 03-Mar-2012 Dimitry Andric <dim@FreeBSD.org>

After r232322, it turned out many people (and some ports) are building
kernel modules using their old installed /usr/share/mk/bsd.*.mk files,
instead of the updated ones in their source tree. This l

After r232322, it turned out many people (and some ports) are building
kernel modules using their old installed /usr/share/mk/bsd.*.mk files,
instead of the updated ones in their source tree. This leads to errors
like:

"sys/conf/kmod.mk", line 111: Malformed conditional (${MK_CLANG_IS_CC} == "no" && ${CC:T:Mclang} != "clang")

Obviously, these errors will go away after a "make installworld", or
alternatively, by using "make buildenv" before attempting to manually
build modules.

However, since it is apparently an expected use case to build using old
.mk files, change the way we test for clang, so it also works when the
MK_CLANG_IS_CC macro doesn't exist.

Note the conditional expressions are becoming rather unreadable now, but
I will attempt to fix that on a followup commit.

MFC after: 2 weeks

show more ...


1...<<11121314151617181920>>...32