descriptors that have the close-on-exec flag set, as that will have no
effect anyway and might screw something else up if the file descriptor
happens to be shared with another process.
PR: standards/43335
MFC after: 1 week
o on input don't strip the Ethernet header from packets
o input packet handling is now done with if_input
o track changes to ether_ifattach/ether_ifdetach API
o track changes to bpf tapping
o call ether_ioctl for default handling of ioctl's
o use constants from net/ethernet.h where possible
Reviewed by: many
Approved by: re
o don't strip the Ethernet header from inbound packets; pass packets
up the stack intact (required significant changes to some drivers)
o reference common definitions in net/ethernet.h (e.g. ETHER_ALIGN)
o track ether_ifattach/ether_ifdetach API changes
o track bpf changes (use BPF_TAP and BPF_MTAP)
o track vlan changes (ifnet capabilities, revised processing scheme, etc.)
o use if_input to pass packets "up"
o call ether_ioctl for default handling of ioctls
Reviewed by: many
Approved by: re
o use if_input for input packet processing
o don't strip the Ethernet header for input packets
o use BPF_* macros bpf tapping
o call ether_ioctl to handle default ioctl case
o track vlan changes
Reviewed by: many
Approved by: re
drivers "tag packets" with an m_tag and the input packet handling recognizes
such packets and does the right thing
o track the number of active vlans on an interface; this lets lots of places
only do vlan-specific processing when needed
o track changes to ether_ifdetach/ether_ifattach
o track bpf changes
o eliminate the use of M_PROTO1 for communicating to drivers about tagged
packets
o eliminate the use of IFF_LINK0 for drivers communicating to the vlan code
that they support h/w tagging; replaced by explicit interface capabilities
o add ifnet capabilities for h/w tagging and support of "large mtu's"
o use new interface capabilities to auto-configure use of large mtu's and h/w
tagging
o add support for proper handling of promiscuous mode
o document driver/vlan communication conventions
Reviewed by: many
Approved by: re
o add if_input member for interface drivers to call through to pass packets "up"
o remove ethernet-specific function decls (moved to ethernet.h)
Reviewed by: many
Approved by: re
ether_header; instead drivers are to leave the Ethernet header at the
front of the packet
o add declarations for netgraph and vlan hooks that were removed from ethernet.h
o change various in-file calling conventions to track change in input API
o fixup bridge support to handle Ethernet header no longer being stripped
o add consistency checks to ether_input to catch problems with the change
in the API; some of these may want to be moved to #ifdef DIAGNOSTIC at a
later time (though they are not too expensive to leave as is)
o change ether_demux to eliminate the passing of the Ethernet header; it is
now expected at the front of the packet a la ether_input
o add ether_sprintf compatibility shim
o change ether_ifattach API to remove "bpf supported param" and add a pointer
to the MAC address to be installed for the LL address (this is for future
changes to divest struct arpcom from struct ifnet)
o change ether_ifdetach API to remove "bpf support param"
Reviewed by: many
Approved by: re
o ETHER_* (ETHER_ALIGN, ETHER_MAX_FRAME, ETHER_CRC_LEN, etc.)
o M_HASFCS for drivers to indicate packets include FCS
o remove global declarations for ng_ether* and vlan_* since these
represent a private contract between the if_ethersubr.c code and
certain parts of the system that should not normally be abused
o add ether_* declarations that were elsewhere
o remove ETHER_BPF_* since they are no longer used with the parameter
no longer passed to ether_ifattach and ether_ifdetach
Reviewed by: many
Approved by: re
o introduce BPF_TAP and BPF_MTAP macros to hide implementation details and
ease code portability
o use m_getcl where appropriate
Reviewed by: many
Approved by: re
Obtained from: NetBSD (multiple link type support)
architecture, mainly to avoid getting a SIGFPE signal sent
when calling strtod(3) with certain input.
The SIGFPE has been sent because the code was not aware that
a Gradual Underflow is handled in software via traps on the
Alpha architecture, but is not implemented in our Alpha kernel
layer.
With `Sudden_Underflow' defined, strtod(3) should not depend
on Gradual Underflow and adjust its calculations accordingly,
which means that other, more subtle errors than the sending of
SIGFPE could be solved by this.
Discussed with: bde
PR: alpha/12623
PR: alpha/17032
PR: alpha/43567
MFC after: 7 days
signed, since they describe a ring buffer and signed arithmetic is
performed on them. This avoids some evilish casts.
Since this changes all but two members of this structure, style(9)
those remaining ones, too.
Requested by: bde
Reviewed by: bde (earlier version)
caused by dynamic PAM modules that call openlog(3) and closelog(3),
e.g. ports/security/pam_pwdfile.
What happened here is that the module first registered its "ident"
with openlog(3), then PAM library unloaded module with dlclose(3),
and the next call to syslog(3) resulted in SIGSEGV.
MFC after: 3 days
the specified filename of the log to be rotated is in fact shell glob
pattern. In this case, all files matching this pattern will be rotated
using the same options. Useful in the case when there is no pre-defined
name for the logfiles (e.g. xtradius, samba etc).
Sponsored by: PortaOne Software Ltd
MFC after: 2 weeks
o Remove the unwanted smartness in _longjmp() where it compares
the current ar.bspstore with the saved ar.bspstore and restores
ar.rnat based on it. This either avoids saving ar.rnat in the
jmp_buf or is the consequence of not saving ar.rnat. All this
complexity breaks libc_r where we use longjmp() to switch to
different threads and the current ar.bspstore has no relation
to the saved ar.bspstore. Thus: we save ar.rnat in setjmp()
and simply restore ar.bspstore and ar.rnat in longjmp().
This code needs a cleanup.
o Use 32-bit unsigned types for things that really are 32-bit quantities,
not bus_addr_t. These are not the same as a bus_addr_t, so don't use
that here. Harmless on i386, introduced problems on sparc64.
Submitted by: jhb
