the mbuf contains the ethernet header (eh) as well, which ether_input()
will strip off as needed.
This permits the removal (in a backward compatible way) of the
header removal code which right now is replicated in all drivers,
sometimes in an inconsistent way. Also, because many functions
called after ether_input() require the eh in the mbuf, eventually
we can propagate the interface and handle outdated drivers just
in ether_input().
Individual driver changes to use the new interface will follow as
we have a chance to touch them.
NOTE THAT THIS CHANGE IS FULLY BACKWARD COMPATIBLE AND DOES NOT BREAK
BINARY COMPATIBILITY FOR DRIVERS.
MFC after: 3 days
Also take this chance to cleanup the code in fxp_intr_body.
Add a missing block of code to disable interrupts when
reinitializing the interface while doing polling (the RELENG_4
version was correct).
MFC after: 3 days
investigate the problem described below.
I am seeing some strange livelock on recent -current sources with
a slow box under heavy load, which disappears with this change.
This might suggest some kind of problem (either insufficient locking,
or mishandling of priorities) in the poll_idle thread.
- v_vflag is protected by the vnode lock and is used when synchronization
with VOP calls is needed.
- v_iflag is protected by interlock and is used for dealing with vnode
management issues. These flags include X/O LOCK, FREE, DOOMED, etc.
- All accesses to v_iflag and v_vflag have either been locked or marked with
mp_fixme's.
- Many ASSERT_VOP_LOCKED calls have been added where the locking was not
clear.
- Many functions in vfs_subr.c were restructured to provide for stronger
locking.
Idea stolen from: BSD/OS
missed the pmap_kenter/kremove in this file, which leads to read()/write()
of /dev/mem using stale TLB entries. (gah!) Fortunately, mmap of /dev/mem
wasn't affected, so it wasn't as bad as it could have been. This throws
some light on the 'X server affects stability' thread....
Pointed out by: bde
cards. Since the firmware is hard coded into the kernel, I've made it
a kernel option (WI_SYMBOL_FIRMWARE).
Note: This only downloads into the RAM of these cards. It doesn't
download into FLASH, and is somewhat limited. There needs to be a
better way to deal, but this works for now. My Symbol LA4132 CF card
works now.
Obtained from: NetBSD
linker_load_module() instead.
This fixes a bug where the kernel was unable to properly locate and
load a kernel module in vfs_mount() (and probably in the netgraph
code as well since it was using the same function). This is because
the linker_load_file() does not properly search the module path.
Problem found by: peter
Reviewed by: peter
Thanks to: peter
kernel access control.
When generating nd6 output on an interface, label the packet
appropriately.
Obtained from: TrustedBSD Project
Sponsored by: DARPA, NAI Labs
case, also preserve the MAC label. Note that this mbuf allocation
is fairly non-optimal, but not my fault.
Obtained from: TrustedBSD Project
Sponsored by: DARPA, NAI Labs
embedded into their file_entry descriptor. This is more for
correctness, since these files cannot be bmap'ed/mmap'ed anyways.
Enforce this restriction.
Submitted by: tes@sgi.com
