sifficient. But somewhere (I believe in the UDP stuff), someone is
overwriting an mbuf without calling m_pullup() first. This results in
broad- and multi-cast traffic that is passed through the bridge getting
corrupted.
This should be backed out when there is some assurance that the upper
layers (and I suppose all of the device drivers) are fixed.
Suggested by: archie
Add correct support for v_object management, so mmap() operation should
work properly.
Add support for extattrctl() routine (submitted by semenu).
At this point nullfs can be considered as functional and much more stable.
In fact, it should behave as a "hard" "symlink" to underlying filesystem.
Reviewed in general by: mckusick, dillon
Parts of logic obtained from: NetBSD
separately (nfs, cd9660 etc) or keept as a first element of structure
referenced by v_data pointer(ffs). Such organization leads to known problems
with stacked filesystems.
From this point vop_no*lock*() functions maintain only interlock lock.
vop_std*lock*() functions maintain built-in v_lock structure using lockmgr().
vop_sharedlock() is compatible with vop_stdunlock(), but maintains a shared
lock on vnode.
If filesystem wishes to export lockmgr compatible lock, it can put an address
of this lock to v_vnlock field. This indicates that the upper filesystem
can take advantage of it and use single lock structure for entire (or part)
of stack of vnodes. This field shouldn't be examined or modified by VFS code
except for initialization purposes.
Reviewed in general by: mckusick
pointer, when bridging and bridge_ipfw are enabled, and when bdg_forward()
happens to free the packet and make our pointer NULL. There may be
more similar problems like this one with calls to bdg_forward().
PR: Related to kern/19551
Reviewed by: jlemon
of the code in the kernel properly checks for read-onlyness before
writing into an mbuf data area. When that code is fixed, the m_dup()
can go back to being m_copypacket().
Requested by: nsayer
PC-card stuff. Also print a NEWLINE (!!) after that.
I'm driving mad each time when I see messages related to pccard before
"Enable PC-card." and particulary when I see
"Doing initial network setup". on the same line w/o a break.
implementation of getaddrinfo() may return NULL ai_canonname.
There is no consensus how getaddrinfo() should fill ai_canonname
when numeric hostname is given.
Reported by: kris
