from the ia32 specific stuff. Some of this still needs to move to the MI
freebsd32 area, and some needs to move to the MD area. This is still
work-in-progress.
commands. Add a quirk for the Creative Nomad MuVo USB device that uses
it as well as NO_SYNCHRONIZE_CACHE.
PR: kern/53094
Submitted by: Richard Nyberg <rnyberg@it.su.se>
MFC after: 3 days
device should handle them.
This prevents for instance GEOM::ioctl requests from reaching a
lower BSDlabel node, which ps@ found would confuse newfs(8).
CB710, CB720, CB1211, CB1225, CB1410 and CB1420
These are likely licensed designed from TI, and the Linux PCMCIA code
treats them as TI chips.
Add comment, but no ID for the 711E1 from O2Micro.
boot time. Instead, read it a sector at a time. While this sounds
like a significant slowdown, I've not been able to measure any
signficant difference.
Submitted by: luigi
Reviewed by: jhb, sam (both a while ago)
MFC After: 3 days
mac_reflect_mbuf_icmp()
mac_reflect_mbuf_tcp()
These entry points permit MAC policies to do "update in place"
changes to the labels on ICMP and TCP mbuf headers when an ICMP or
TCP response is generated to a packet outside of the context of
an existing socket. For example, in respond to a ping or a RST
packet to a SYN on a closed port.
Obtained from: TrustedBSD Project
Sponsored by: DARPA, Network Associates Laboratories
mac_reflect_mbuf_icmp()
mac_reflect_mbuf_tcp()
These entry points permit MAC policies to do "update in place"
changes to the labels on ICMP and TCP mbuf headers when an ICMP or
TCP response is generated to a packet outside of the context of
an existing socket. For example, in respond to a ping or a RST
packet to a SYN on a closed port.
Obtained from: TrustedBSD Project
Sponsored by: DARPA, Network Associates Laboratories
change in mac_lomac: if both flags are set on the new label, we
may not need to always fill out the label (only if one flag is
set, not both). Avoid stomping on a section of the label if we
are in fact modifying both elements.
Because we know that both flags will be set, we don't need to
test whether the range or single are set in later consistency
checks of the range and single -- just test them.
By checking the range of the new vs. the range of the old label
before testing the single against the new range, we implicitly
test that the new single is in the old range. Document this
with a comment.
Obtained from: TrustedBSD Project
Sponsored by: DARPA, Network Associates Laboratories
vendors that list the vendor ID in the proper byte order. The second
section is for vendors that get it backwards. The third is for what
appear to be 'random' ones (although 0xcxxx appears to be coherent
enough that maybe somebody else is assigning those numbers).
