These files contained various combinations of Big5, eucJP and KOI8-U
encoded strings. The byte representations of their respective encodings
have been translated to $'...' escape sequences as understood by our sh(1).
With help from: jilles
- Device configuration via plain text config file. Also able to operate
when not attached to the chip as the master driver.
- Generic "work request" queue that serves as the base for both ctrl and
ofld tx queues.
- Generic interrupt handler routine that can process any event on any
kind of ingress queue (via a dispatch table).
- A couple of new driver ioctls. cxgbetool can now install a firmware
to the card ("loadfw" command) and can read the card's memory
("memdump" and "tcb" commands).
- Lots of assorted information within dev.t4nex.X.misc.* This is
primarily for debugging and won't show up in sysctl -a.
- Code to manage the L2 tables on the chip.
- Updates to cxgbe(4) man page to go with the tunables that have changed.
- Updates to the shared code in common/
- Updates to the driver-firmware interface (now at fw 1.4.16.0)
MFC after: 1 month
- While here, make this compile and work on non-i386:
- Use CMSG_SPACE(), CMSG_LEN(), and CMSG_FIRSTHDR() instead of ignoring
padding between 'struct cmsghdr' and control message payloads.
- Don't initialize the control message before calling recvmsg().
Instead, check that we get a valid control message on return from
recvmsg().
- Use errx() instead of err() for some errors that don't report failures
that set errno.
Requested by: kib (1)
A link reset now is completely transparent for the netmap client:
even if the NIC resets its own ring (e.g. restarting from 0),
the client will not see any change in the current rx/tx positions,
because the driver will keep track of the offset between the two.
2. make the device-specific code more uniform across different drivers
There were some inconsistencies in the implementation of the netmap
support routines, now drivers have been aligned to a common
code structure.
3. import netmap support for ixgbe . This is implemented as a very
small patch for ixgbe.c (233 lines, 11 chunks, mostly comments:
in total the patch has only 54 lines of new code) , as most of
the code is in an external file sys/dev/netmap/ixgbe_netmap.h ,
following some initial comments from Jack Vogel about making
changes less intrusive.
(Note, i have emailed Jack multiple times asking if he had
comments on this structure of the code; i got no reply so
i assume he is fine with it).
Support for other drivers (em, lem, re, igb) will come later.
"ixgbe" is now the reference driver for netmap support. Both the
external file (sys/dev/netmap/ixgbe_netmap.h) and the device-specific
patches (in sys/dev/ixgbe/ixgbe.c) are heavily commented and should
serve as a reference for other device drivers.
Tested on i386 and amd64 with the pkt-gen program in tools/tools/netmap,
the sender does 14.88 Mpps at 1050 Mhz and 14.2 Mpps at 900 MHz
on an i7-860 with 4 cores and 82599 card. Haven't tried yet more
aggressive optimizations such as adding 'prefetch' instructions
in the time-critical parts of the code.
The "domain-search" option (option 119) allows a DHCP server to publish
a list of implicit domain suffixes used during name lookup. This option
is described in RFC 3397.
For instance, if the domain-search option says:
".example.org .example.com"
and one wants to resolve "foobar", the resolver will try:
1. "foobar.example.org"
2. "foobar.example.com"
The file /etc/resolv.conf is updated with a "search" directive if the
DHCP server provides "domain-search".
A regression test suite is included in this patch under
tools/regression/sbin/dhclient.
PR: bin/151940
Sponsored by Yakaz (http://www.yakaz.com)
- plus: execute "+command" when run with -jX -n
- ellipsis: ellipsis ("...") from variable
- empty: empty command (from variable)
Currently make(1) fails all three tests:
- plus: segmentation fault due to incorrect command list handling
- ellipsis: works in compat mode but fails in job (-jX) mode
- empty:
- compat mode: prints error message
- job mode: works but prints empty string
allow the built-in operations to be redefined, at least not without
excessive force).
Instead, just disable LLVM's support for atomic operations for now.
Nothing in either clang or the tablegen tools currently depends on it.
This still allows users of head built before r198344 to upgrade to
top-of-head seamlessly.
I/O from userspace, capable of line rate at 10G, see
http://info.iet.unipi.it/~luigi/netmap/
At this time I am bringing in only the generic code (sys/dev/netmap/
plus two headers under sys/net/), and some sample applications in
tools/tools/netmap. There is also a manpage in share/man/man4 [1]
In order to make use of the framework you need to build a kernel
with "device netmap", and patch individual drivers with the code
that you can find in
sys/dev/netmap/head.diff
The file will go away as the relevant pieces are committed to
the various device drivers, which should happen in a few days
after talking to the driver maintainers.
Netmap support is available at the moment for Intel 10G and 1G
cards (ixgbe, em/lem/igb), and for the Realtek 1G card ("re").
I have partial patches for "bge" and am starting to work on "cxgbe".
Hopefully changes are trivial enough so interested third parties
can submit their patches. Interested people can contact me
for advice on how to add netmap support to specific devices.
CREDITS:
Netmap has been developed by Luigi Rizzo and other collaborators
at the Universita` di Pisa, and supported by EU project CHANGE
(http://www.change-project.eu/)
The code is distributed under a BSD Copyright.
[1] In my opinion is a bad idea to have all manpage in one directory.
We should place kernel documentation in the same dir that contains
the code, which would make it much simpler to keep doc and code
in sync, reduce the clutter in share/man/ and incidentally is
the policy used for all of userspace code.
Makefiles and doc tools can be trivially adjusted to find the
manpages in the relevant subdirs.
emits calls for them, rather than expanding them inline. Older FreeBSD
versions compile for i386 by default and as such we end up with
unresolved symbols when we build LLVM's TableGen utility as a build
tool on them. Add the functions that GCC emits here, but don't bother
to make them atomic. Such is not needed.
Submitted by: marcel
MFC after: 1 week
POSIX says the exit status of a for loop without any items shall be 0. There
are no exceptions if the exit status of the previous command was not 0 or if
the item list contains a command substitution with non-zero exit status.
old distfile directory as primary source:
mkdir /freebsd/ports/distfiles.old
mv /freebsd/ports/distfiles/* /freebsd/ports/distfiles.old
sh sysbuild.sh -c $yourconfig -P /freebsd/ports/distfiles.old
rm -rf /freebsd/ports/distfiles.old
Unfortunately bsd.ports.mk does not attempt to use a hard-link so
while this runs you need diskspace for both your old and your "new"
distfiles.
introduce zfsboottest.sh script that will verify if it will be possible to boot
from the given pool.
# zfsboottest.sh system
Where "system" is pool name of the pool we want to boot from.
What is being verified by the script:
- Does the pool exist?
- Does it have bootfs property configured?
- Is mountpoint property of the boot dataset set to 'legacy'?
Dataset configured in bootfs property has to be mounted to perform more
checks:
- Does the /boot directory in boot dataset exist?
- Is this dataset configured as root file system in /etc/fstab or set
in vfs.root.mountfrom variable in /boot/loader.conf?
By using zfsboottest tool the script will read all the files in /boot
directory using ZFS boot code and calculate their checksums.
Then, it will walk /boot directory using find(1) though regular file sytem
and also read all the files in /boot directory and calculate their checksums.
If any of the files cannot be looked up, read or checksum is invalid it will
be reported and booting off of this pool is probably not possible.
Some additional checks may be interesting as well. For example if the disks
contain proper pmbr and gptzfsboot code or if all expected files in /boot/
are present.
When upgrading FreeBSD, one should snapshot datasets that contain operating
system, upgrade (install new world and kernel) and use zfsboottest.sh to verify
if it will be possible to boot from new configuration. If all is good one
should upgrade boot blocks, by eg.:
# gpart -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada1
If something is wrong, one should rollback datasets and report the problems.
MFC after: 3 days
zfsboottest gpt/system0 gpt/system1 - /boot/kernel/kernel /boot/zfsloader
- Instead of printing file's content calculate MD5 hash of the file,
so it can be easly compared to the hash calculated via file system.
- Some other minor improvements.
MFC after: 3 days
