Before:
$ ipfw -n add 100 count icmp from any to any mac-type 0x01
00100 count icmp 0x0001
$ ipfw -n add 100 count icmp from any to any mac any any
00100 count icmp MAC any any any
After:
$ ipfw -n add 100 count icmp from any to any mac-type 0x01
00100 count icmp from any to any mac-type 0x0001
$ ipfw -n add 100 count icmp from any to any mac any any
00100 count icmp from any to any MAC any any
PR: bin/112244
Submitted by: Andrey V. Elsukov
MFC after: 1 month
(also IEEE Std 1003.1-2001)
The specs explicitly says that altering passed string
should change the environment, i.e. putenv() directly puts its arg
into environment (unlike setenv() which just copies it there).
It means that putenv() can't be implemented via setenv()
(like we have before) at all. Putenv() value lives (allows modifying)
up to the next putenv() or setenv() call.
- Wake up DMA engine after adding a new receive buffer.
- Skip buffers which have unknown state after error.
- More rigid error detection.
MFC after: 1 week
Rationale:
We are interested in the current (last) element of the argv array
there, not in its first element. The if construct is there because
we want to avoid adding empty (zero-length) arguments to argv, so
we just don't advance argvp if the current argument is empty, and
it gets overwritten at the next iteration. Note that strsep(3)
doesn't treat consecutive delim characters as a single separator,
it returns empty fields between such characters, and it's up to the
caller to handle them this or that way.
Also add a comment that the argv array ends up null-terminated in
any case (it's due to the design of the for loop) as an answer to
a possible question why the whole argv isn't zero-filled.
Submitted by: yongari
Tested by: yongari
MFC after: 3 days
o Print "unknown ICMP" instead of "(null)" if we don't have a description for a icmp type.
Based on code
Submitted by: Christoph Weber-Fahr
PR: misc/112126
MFC after: 2 weeks
1) Under POSIX unsetenv("foo=bar") is explicit error and not equal
to unsetenv("foo")
2) Prepare for upcomig POSIXed putenv() rewrite: make putenv() calls
portable and conforming to standard.
as some combinations of chipset, controller and target do not behave
correctly when DMA is enabled for other commands.
PR: kern/103602
MFC after: 2 weeks
compatibility with the different environment conventions" (man page).
With the standards, we don't have them different anymore and
IEEE Std 1003.1-2001 says that
"The values that the environment variables may be assigned are not
restricted except that they are considered to end with a null byte"
Issue 6 (also IEEE Std 1003.1-2001) in following areas:
args, return, errors.
Putenv still needs rewriting because specs explicitly says that
altering passed string later should change the environment (currently we
copy the string so can't provide that).
to override weak symbols exported by libc, so by definition these two
are using the same symbol version names.
Reflect the reality by referring to libc's Versions.def directly.
- edsc(4) added
- pmcstat(4) -c and -t flags, defaults changed
- rpcbind -h and -6 flags
Modified release notes:
- Moved pmcstat information from kernel to userland section
- MSI-X supported as well, remove ref to pci(4) manpage, which is
different from the kernel's PCI code
- rpc.lockd/rpc.statd entry moved to the right place
