that was fixed by this should not normally happen, and since I did not
record the traces of my failed build attempt that had been solved with
that change, it's not entirely clear whether it hadn't been a pilot
error on my end. In dubio pro reo. :-)
subset ("compatible", "device_type", "model" and "name") of the standard
properties in drivers for devices on Open Firmware supported busses. The
standard properties "reg", "interrupts" und "address" are not covered by
this interface because they are only of interest in the respective bridge
code. There's a remaining standard property "status" which is unclear how
to support properly but which also isn't used in FreeBSD at present.
This ofw_bus kobj-interface allows to replace the various (ebus_get_node(),
ofw_pci_get_node(), etc.) and partially inconsistent (central_get_type()
vs. sbus_get_device_type(), etc.) existing IVAR ones with a common one.
This in turn allows to simplify and remove code-duplication in drivers for
devices that can hang off of more than one OFW supported bus.
- Convert the sparc64 Central, EBus, FHC, PCI and SBus bus drivers and the
drivers for their children to use the ofw_bus kobj-interface. The IVAR-
interfaces of the Central, EBus and FHC are entirely replaced by this. The
PCI bus driver used its own kobj-interface and now also uses the ofw_bus
one. The IVARs special to the SBus, e.g. for retrieving the burst size,
remain.
Beware: this causes an ABI-breakage for modules of drivers which used the
IVAR-interfaces, i.e. esp(4), hme(4), isp(4) and uart(4), which need to be
recompiled.
The style-inconsistencies introduced in some of the bus drivers will be
fixed by tmm@ in a generic clean-up of the respective drivers later (he
requested to add the changes in the "new" style).
- Convert the powerpc MacIO bus driver and the drivers for its children to
use the ofw_bus kobj-interface. This invloves removing the IVARs related
to the "reg" property which were unused and a leftover from the NetBSD
origini of the code. There's no ABI-breakage caused by this because none
of these driver are currently built as modules.
There are other powerpc bus drivers which can be converted to the ofw_bus
kobj-interface, e.g. the PCI bus driver, which should be done together
with converting powerpc to use the OFW PCI code from sparc64.
- Make the SBus and FHC front-end of zs(4) and the sparc64 eeprom(4) take
advantage of the ofw_bus kobj-interface and simplify them a bit.
Reviewed by: grehan, tmm
Approved by: re (scottl)
Discussed with: tmm
Tested with: Sun AX1105, AXe, Ultra 2, Ultra 60; PPC cross-build on i386
namespace. This is to allow decoupling of attachments from ACPI where they
need some functionality when ACPI is present but do not want to require ACPI
to always be loaded.
your (network) modules as well as any userland that might make sense of
sizeof(struct ifnet).
This does not change the queueing yet. These changes will follow in a
seperate commit. Same with the driver changes, which need case by case
evaluation.
__FreeBSD_version bump will follow.
Tested-by: (i386)LINT
all of the interface between the driver and the bus. This will enable
us to stop special casing eisa bus attachments in modules and treat them
like we treat all other busses.
In the longer run, we need to eliminate much (all?) of these interfaces
and switch to using the standard bus_alloc_resource(), but that's not
done right now.
# I've not updated the modules to include eisa, etc, just yet
Tested on: Compaq Proliant 3000/333 purchased for eisa work
converts miidevs to a .h file, so rename to reflect that.
The usb and pccard versions have also been renamed and will be hooked
into the build system shortly (I've made the conversion in my p4
tree).
yet, but building kld's is OK now and they can be loaded by kldload(2).
(but the machine will likely crash soon afterwards, a "minor" problem :-)
Brought to you by: my injured knee (from moving)
Fix 'broken' ifdefs.
icc does not support profiling yet so remove unfinished code which was
supposed to help.
Submitted by: netchild (original version)
Reviewed by: ru
Intel C/C++ compiler (lang/icc) to build the kernel.
The icc CPUTYPE CFLAGS use icc v7 syntax, icc v8 moans about them, but
doesn't abort. They also produce CPU specific code (new instructions
of the CPU, not only CPU specific scheduling), so if you get coredumps
with signal 4 (SIGILL, illegal instruction) you've used the wrong
CPUTYPE.
Incarnations of this patch survive gcc compiles and my make universe.
I use it on my desktop.
To use it update share/mk, add
/usr/local/intel/compiler70/ia32/bin (icc v7, works)
or
/usr/local/intel_cc_80/bin (icc v8, doesn't work)
to your PATH, make sure you have a new kernel compile directory
(e.g. MYKERNEL_icc) and run
CFLAGS="-O2 -ip" CC=icc make depend
CFLAGS="-O2 -ip" CC=icc make
in it.
Don't compile with -ipo, the build infrastructure uses ld directly to
link the kernel and the modules, but -ipo needs the link step to be
performed with Intel's linker.
Problems with icc v8:
- panic: npx0 cannot be emulated on an SMP system
- UP: first start of /bin/sh results in a FP exception
Parts of this commit contains suggestions or submissions from
Marius Strobl <marius@alchemy.franken.de>.
Reviewed by: silence on -arch
Submitted by: netchild
to one, DEBUG_FLAGS, which is also compatible with <bsd.prog.mk>.
Previously one had to set both DEBUG and DEBUG_FLAGS to build the
.ko.debug with debugging symbols which was boring when doing this
manually.
regocnized as such at the time. Now that the other bogons in the
tree have been fixed, we can remove this ugly kludge.
o Remove stale/bogus opt_foo.h files. These are left over from
by-gone resources. And they point to the need, yet again, to
improve the build system so meta information is only in one place.
Submitted by: ru
Reviewed by: bde
Approved by: re@ (jhb)
I'm having bad luck with different parts of the sys tree being checked
out at slightly different times. Back it out, noting it doesn't cause
harm in any case. Tinderbox also makes these things more fun.
opt_ddb.h. These changes expand green's work of including
opt_global.h to prefer opt files in the kernel directory. Further
refinement might be needed, but I think this is good.
Note: While this is a step on the path to moving the meta information
about modules into the config files, it doesn't actually do that. It
just pulls in the opt files in a way that allows one to build
'generic' modules outside the tree.
kernel build. This makes it possible for me not to get pissed off that
random.ko crashes the system trying to rdtsc() when the i386/cpu.h
support code decides it's okay to call that op when neither I386_CPU or
I486_CPU is defined. I guess it also makes WITNESS/INVARIANTS defines
get picked up by the modules.
the amd64 implementation of the pcpu macros is even more verbose than on
i386 and that causes gcc to way overestimate the complexity of this
2-instruction macro. The other platforms can probably lower their
default values.
been widely deploy and that's causing us a lot of pain. Back out the
last commit for a few weeks so that we can lessen the support load in
current@ asking why they can't build kernels anymore. Instructions in
UPDATING have been updated, but this should be more effective.
Revert the reverting: November 1st, 2003
of what uart(4) is and/or is not see the initial commit log of one
of the files in sys/dev/uart (or see share/man/man4/uart.4).
Note that currently pc98 shares the MD file with i386. This needs
to change when pc98 support is fleshed-out to properly support the
various UARTs. A good example is sparc64 in this respect.
We build uart(4) as a module on all platforms. This may break
the ppc port. That depends on whether they do actually build
modules.
To use uart(4) on alpha, one must use the NO_SIO option.
set an initial value. This is aimed at getting us closer to being able to
turn -Werror back on and we can adjust the settings later on. Yes, we
could turn off -Wno-inline instead, but that would hide the effect of
gcc's bogo-estimator ignoring inline (either rightly or wrongly).
Always use sys/conf/kern.mk when building kernel/modules.
<bsd.kern.mk> is only preserved for sys/boot/pc98/boot2
for now, but this will be fixed. If there are other
users of <bsd.kern.mk>, please let me know.
Reminded by: bde
module dependency system rely on linker behaviour that is machine dependent
and not part of the elf spec, and only work by accident on other platforms.
Approved by: re
under way to move the remnants of the a.out toolchain to ports. As the
comment in src/Makefile said, this stuff is deprecated and one should not
expect this to remain beyond 4.0-REL. It has already lasted WAY beyond
that.
Notable exceptions:
gcc - I have not touched the a.out generation stuff there.
ldd/ldconfig - still have some code to interface with a.out rtld.
old as/ld/etc - I have not removed these yet, pending their move to ports.
some includes - necessary for ldd/ldconfig for now.
Tested on: i386 (extensively), alpha
available from bsd.obj.mk.
The native version was identical (and pretty much unused except in
the -DMODULES_WITH_WORLD case, which it is not for "make release")
except that the "bin" -> "base" change of the default DISTRIBUTION
name did not propagate here.
'make load' if an object dir was, like it is used in /sys/modules. I.e.
cd /sys/modules/umass
make obj
make
make load
works again without having to install the module.
If no objdir was used the module in the current directory is used.
