This will not make any of object files that LINT create change; there
might be differences with INET disabled, but hardly anything compiled
before without INET anyway. Now the 'obvious' things will give a
proper error if compiled without inet - ipx_ip, ipfw, tcp_debug. The
only thing that _should_ work (but can't be made to compile reasonably
easily) is sppp :-(
This commit move struct arpcom from <netinet/if_ether.h> to
<net/if_arp.h>.
to define it by including <sys/kernel.h>. That broke PC-CARD
support for this driver, producing the dreaded "device allocation
failed" message. Surprisingly, the missing include caused only
two compiler warnings. The compilation still "succeeded" anyway.
use a Linker Set. Note, if a driver is loaded as an LKM if will have
to use the function call, but since none of the existing drivers
are loadable, this made things cleaner and boot messages nicer.
Obtained from: PAO-970616
* Kill individual drivers 'suspend' routines, since there's no simple/safe
way to suspend/resume a card w/out going through the complete probe
at initialization time.
* Default to using the apm_pccard_resume sysctl code, which basically
pretends the card was removed, and then re-inserted. Suspend/resume
is now 'emulated' with a fake insert/removal. (Hence we no longer
need the driver-specific suspend routines.)
follow.
* Rename/reorder all of the pccard structures, change many of the member
names to be descriptive, and follow more closely other 'bus' drivers
naming schemes.
* Rename a bunch of parameter and local variable names to be more
consistant in the code.
* Renamed the PCCARD 'crd' device to be the 'card' device
* KNF and make the code consistant where it was obvious.
* ifdef'd out some unused code
shown to be harmful in that it results in the card not being detected
properly on warmboot due to the station address failing to be read
correctly from the NVRAM.
delay that without this the performance is unacceptable. The 83C690,
83C790, and 83C795 chips which this affects are all designed to work
with 0 waitstates in 16bit mode.
Also cleaned up the toggling of 16bit access mode that occurs during
normal operation; the previous code may not have done the right thing
in all cases.
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
previous hackery involving struct in_ifaddr and arpcom. Get rid of the
abominable multi_kludge. Update all network interfaces to use the
new machanism. Distressingly few Ethernet drivers program the multicast
filter properly (assuming the hardware has one, which it usually does).
to TAILQs. Fix places which referenced these for no good reason
that I can see (the references remain, but were fixed to compile
again; they are still questionable).
type to be int so that errors can be returned.
2) Use the new SIOCSIFMTU ether_ioctl support in the few drivers that are
using ether_ioctl().
3) In if_fxp.c: treat if_bpf as a token, not as a pointer. Don't bother
testing for FXP_NTXSEG being reached in fxp_start()...just check for
non-NULL 'm'. Change fxp_ioctl() to use ether_ioctl().
function ed_attach_NE2000_pci() in if_ed.c passes
an uninitialized block of memory (got with malloc())
to ed_attach. This prevents a proper initialization
of the device descriptor and in my case causes a panic
during the probe, while printing out device info.
Reviewed by: phk
Submitted by: Luigi Rizzo <luigi@iet.unipi.it>
is only used by the icu support modules and by a few drivers that know
too much about the icu (most only use it to convert `n' to `IRQn'). isa.h
is only used by ioconf.c and by a few drivers that know too much about
isa addresses (a few have to, because config is deficient).
All new code is "#ifdef PC98"ed so this should make no difference to
PC/AT (and its clones) users.
Ok'd by: core
Submitted by: FreeBSD(98) development team
is enabled by having an "device ed0 at isa? [...]" config line.
The first PCI card will get a unit number one higher than the highest
defined for any ISA card of the ED type, e.g. if ed0 and ed1 are
configured, then the PCI cards will be ed2, ed3, ...
BEWARE: If you have configured your kernel as ed0 with the port address
as assigned by the PCI BIOS, then your card will be found by both the
PCI and ISA probes, and bad things may happen. Make sure to restore
the original port address form the GENERIC kernel for the ed0 device!
Reviewed by: davidg
