Since I've committed this I've receieved roughly an equal
amount of email thanking me for making this change
and asking me to revert it.
I've resisted making this change because
new users tend to prefer less over more
and these users are the least likely to know
how to change the PAGER on their own.
Requested by: many
Objected to: just as many
Decision made by: core
Approved by: cperciva
MFC after: 3 days
provide this information along with messages documentation,
like this done in manual pages for other netgraph nodes.
Submitted by: Mamontov Roman <mr.xanto gmail.com>
Allow textdumps to be called explicitly from DDB.
If "dump" is called in DDB and textdumps are enabled then abort the
dump and tell the user to turn off textdumps.
Add options TEXTDUMP_PREFERRED to turn textdumps on by default.
Add options TEXTDUMP_VERBOSE to be a bit more verbose while textdumping.
Reviewed by: rwatson
MFC after: 2 weeks
RocketRAID 4500 series.
Many thanks to HighPoint Technologies for their continued support
of FreeBSD!
Submitted by: HighPoint Technologies
MFC after: 3 days
on the related functionality in the runtime via the sysctl variable
net.pfil.forward. It is turned off by default.
Sponsored by: Yandex LLC
Discussed with: net@
MFC after: 2 weeks
In particular, do not lock Giant conditionally when calling into the
filesystem module, remove the VFS_LOCK_GIANT() and related
macros. Stop handling buffers belonging to non-mpsafe filesystems.
The VFS_VERSION is bumped to indicate the interface change which does
not result in the interface signatures changes.
Conducted and reviewed by: attilio
Tested by: pho
filters (ipfw and PF) use the same ruleset with the same lock for both
AF_INET and AF_INET6 there is no need in more fine-grade locking.
However, it is possible to request personal lock by specifying
PFIL_FLAG_PRIVATE_LOCK flag in pfil_head structure (see pfil.9 for
more details).
Export PFIL lock via rw_lock(9)/rm_lock(9)-like API permitting pfil consumers
to use this lock instead of own lock. This help reducing locks on main
traffic path.
pfil_assert() is currently not implemented due to absense of rm_assert().
Waiting for some kind of r234648 to be merged in HEAD.
This change is part of bigger patch reducing routing locking.
Sponsored by: Yandex LLC
Reviewed by: glebius, ae
OK'd by: silence on net@
MFC after: 3 weeks
but committing it helps to get everyone on the same page and makes
sure we make progress.
Tinderbox breakages that are the result of this commit are entirely
the committer's fault -- in other words: buildworld testing on amd64
only.
Credits follow:
Submitted by: Garrett Cooper <yanegomi@gmail.com>
Sponsored by: Isilon Systems
Based on work by: keramida@
Thanks to: gnn@, mdf@, mlaier@, sjg@
Special thanks to: keramida@
1. Have the resulting C file depend on the resulting H
file as it should be. Touch the C file to make sure
the C file is newer than the H file to keep make
happy.
2. Apply the same fix to the other instance of .ORDER,
missed in the previous commit.
available to the user. Should be applicable to all branches and versions
where est(4) exists.
thanks to gjb for reviewing and suggesting nits
Reviewed by: gjb@
MFC after: 2 weeks
GIANT from VFS. In addition, disconnect also netsmb, which is a base
requirement for SMBFS.
In the while SMBFS regular users can use FUSE interface and smbnetfs
port to work with their SMBFS partitions.
Also, there are ongoing efforts by vendor to support in-kernel smbfs,
so there are good chances that it will get relinked once properly locked.
This is not targeted for MFC.
GIANT from VFS. This code is particulary broken and fragile and other
in-kernel implementations around, found in other operating systems,
don't really seem clean and solid enough to be imported at all.
If someone wants to reconsider in-kernel NTFS implementation for
inclusion again, a fair effort for completely fixing and cleaning it
up is expected.
In the while NTFS regular users can use FUSE interface and ntfs-3g
port to work with their NTFS partitions.
This is not targeted for MFC.
GIANT from VFS. In addition, disconnect also netncp, which is a base
requirement for NWFS.
In the possibility of a future maintenance of the code and later
readd to the FreeBSD base, maybe we should think about a better location
for netncp. I'm not entirely sure the / top location is actually right,
however I will let network people to comment on that more specifically.
This is not targeted for MFC.
1. Don't do upgrade_checks when using bmake. As long as we have WITH_BMAKE,
there's a bootstrap complication in ths respect. Avoid it. Make the
necessary changes to have upgrade_checks work wth bmake anyway.
2. Remove the use of -E. It's not needed in our build because we use ?= for
the respective variables, which means that we'll take the environment
value (if any) anyway.
3. Properly declare phony targets as phony as bmake is a lot smarter (and
thus agressive) about build avoidance.
4. Make sure CLEANFILES is complete and use it on .NOPATH. bmake is a lot
smarter about build avoidance and should not find files we generate in
the source tree. We should not have files in the repository we want to
generate, but this is an easier way to cross this hurdle.
5. Have behavior under bmake the same as it is under make with respect to
halting when sub-commands fail. Add "set -e" to compound commands so
that bmake is informed when sub-commands fail.
6. Make sure crunchgen uses the same make as the rest of the build. This
is important when the make utility isn't called make (but bmake for
example).
7. While here, add support for using MAKEOBJDIR to set the object tree
location. It's the second alternative bmake looks for when determining
the actual object directory (= .OBJDIR).
Submitted by: Simon Gerraty <sjg@juniper.net>
Submitted by: John Van Horne <jvanhorne@juniper.net>
of FreeBSD's make by setting WITH_BMAKE. The WITH_BMAKE build makes it
easy for people to switch while working out the kinks -- think ports
tree here. The option will be removed in due time.
Submitted by: Simon Gerraty (sjg@juniper.net)
- All packets in NETISR_IP queue are in net byte order.
- ip_input() is entered in net byte order and converts packet
to host byte order right _after_ processing pfil(9) hooks.
- ip_output() is entered in host byte order and converts packet
to net byte order right _before_ processing pfil(9) hooks.
- ip_fragment() accepts and emits packet in net byte order.
- ip_forward(), ip_mloopback() use host byte order (untouched actually).
- ip_fastforward() no longer modifies packet at all (except ip_ttl).
- Swapping of byte order there and back removed from the following modules:
pf(4), ipfw(4), enc(4), if_bridge(4).
- Swapping of byte order added to ipfilter(4), based on __FreeBSD_version
- __FreeBSD_version bumped.
- pfil(9) manual page updated.
Reviewed by: ray, luigi, eri, melifaro
Tested by: glebius (LE), ray (BE)
tree used it incorrectly, which lead to inaccurate overrated
if_obytes accounting. The drbr(9) used to update ifnet stats on
drbr_enqueue(), which is not accurate since enqueuing doesn't
imply successful processing by driver. Dequeuing neither mean
that. Most drivers also called drbr_stats_update() which did
accounting again, leading to doubled if_obytes statistics. And
in case of severe transmitting, when a packet could be several
times enqueued and dequeued it could have been accounted several
times.
o Thus, make drbr(9) API thinner. Now drbr(9) merely chooses between
ALTQ queueing or buf_ring(9) queueing.
- It doesn't touch the buf_ring stats any more.
- It doesn't touch ifnet stats anymore.
- drbr_stats_update() no longer exists.
o buf_ring(9) handles its stats itself:
- It handles br_drops itself.
- br_prod_bytes stats are dropped. Rationale: no one ever
reads them but update of a common counter on every packet
negatively affects performance due to excessive cache
invalidation.
- buf_ring_enqueue_bytes() reduced to buf_ring_enqueue(), since
we no longer account bytes.
o Drivers handle their stats theirselves: if_obytes, if_omcasts.
o mlx4(4), igb(4), em(4), vxge(4), oce(4) and ixv(4) no longer
use drbr_stats_update(), and update ifnet stats theirselves.
o bxe(4) was the most correct driver, it didn't call
drbr_stats_update(), thus it was the only driver accurate under
moderate load. Now it also maintains stats itself.
o ixgbe(4) had already taken stats from hardware, so just
- drop software stats updating.
- take multicast packet count from hardware as well.
o mxge(4) just no longer needs NO_SLOW_STATS define.
o cxgb(4), cxgbe(4) need no change, since they obtain stats
from hardware.
Reviewed by: jfv, gnn
When the compiler is clang add c++11 to COMPILER_FEATURES.
When the compiler supports c++11, default to building libc++. This will
not impact the compliation of programs, but will make it easier for
users with clang compiled systems to test libc++ by passing -stdlib=libc++
to their c++ compliations.
While here increase the suggested sizes for the
partition as "make universe" takes a lot more
space than mentioned.
Reviewed by: gavin
Approved by: gjb
MFC after: 3 days
X-MFC-With: r240728
This is important to secure a small timeframe at boot time, when
network is already configured, but pf(4) is not yet.
PR: kern/171622
Submitted by: Olivier Cochard-LabbИ <olivier cochard.me>
- Remove cvs(1) references.
- Remove CVS* environment references.
- Add default entries for the default SVNROOT for the Ports
Collection, and Documentation Project.
- While here, update 'SGML-based documentation' to 'XML-based',
since the recent SGML->XML conversion.
- Update an example providing SVNROOT environment usage.
Reminded by: nwhitehorn
MFC After: 1 week
X-MFC-With: r240586, r240587
reside, and move there ipfw(4) and pf(4).
o Move most modified parts of pf out of contrib.
Actual movements:
sys/contrib/pf/net/*.c -> sys/netpfil/pf/
sys/contrib/pf/net/*.h -> sys/net/
contrib/pf/pfctl/*.c -> sbin/pfctl
contrib/pf/pfctl/*.h -> sbin/pfctl
contrib/pf/pfctl/pfctl.8 -> sbin/pfctl
contrib/pf/pfctl/*.4 -> share/man/man4
contrib/pf/pfctl/*.5 -> share/man/man5
sys/netinet/ipfw -> sys/netpfil/ipfw
The arguable movement is pf/net/*.h -> sys/net. There are
future plans to refactor pf includes, so I decided not to
break things twice.
Not modified bits of pf left in contrib: authpf, ftp-proxy,
tftp-proxy, pflogd.
The ipfw(4) movement is planned to be merged to stable/9,
to make head and stable match.
Discussed with: bz, luigi
type of compiler is being used (currently clang or gcc). COMPILER_TYPE
is set in the new bsd.compiler.mk file based on the value of the CC
variable or, should it prove informative, by running ${CC} --version
and examining the output.
To avoid negative performance impacts in the default case and correct
value for COMPILER_TYPE type is determined and passed in the environment
of submake instances while building world.
Replace adhoc attempts at determining the compiler type by examining
CC or MK_CLANG_IS_CC with checks of COMPILER_TYPE. This eliminates
bootstrapping complications when first setting WITH_CLANG_IS_CC.
Sponsored by: DARPA, AFRL
Reviewed by: Yamaya Takashi <yamayan@kbh.biglobe.ne.jp>, imp, linimon
(with some modifications post review)
MFC after: 2 weeks
Regular LISTs have been implemented in such a way that the prev-pointer
does not point to the previous element, but to the next-pointer stored
in the previous element. This is done to simplify LIST_REMOVE(). This
macro can be implemented without knowing the address of the list head.
Unfortunately this makes it harder to implement LIST_PREV(), which is
why this macro was never here. Still, it is possible to implement this
macro. If the prev-pointer points to the list head, we return NULL.
Otherwise we simply subtract the offset of the prev-pointer within the
structure.
It's not as efficient as traversing forward of course, but in practice
it shouldn't be that bad. In almost all use cases, people will want to
compare the value returned by LIST_PREV() against NULL, so an optimizing
compiler will not emit code that does more branching than TAILQs.
While there, make the code a bit more readable by introducing
__member2struct(). This makes STAILQ_LAST() far more readable.
MFC after: 1 month
Update the Vendor Relations Team information to reflect that
incoming email is now handled by core@ and the Foundation.
Reviewed by: gjb
MFC after: 3 days
Specifically document that an incomplete ports tree is not supported.
Remove useless comment about sendmail.
Reviewed by: yuri.pankov@gmail.com
Approved by: cperciva (implicit)
MFC after: 1 week
X-MFC-With: r240252
current link points to a irrelevant catchall site.
PR: docs/171411
Submitted by: Mark Martinec <Mark.Martinec@ijs.si> (pr), me (patch)
Approved by: joel (mentor)
MFC after: 2 weeks
- Provide missing function that can do hashing of arbitrary sized buffer.
- Refetch lookup3.c and do only minimal edits to it, so that diff between
our jenkins_hash.c and lookup3.c is minimal.
- Add declarations for jenkins_hash(), jenkins_hash32() to sys/hash.h.
- Document these functions in hash(9)
Obtained from: http://burtleburtle.net/bob/c/lookup3.c
used with Terasic's DE-4 and other similar FPGA boards. This display
is 800x480 and includes a capacitive touch screen, multi-touch
gesture recognition, etc. This device driver depends on a Cambridge-
provided IP core that allows the MTL device to be hooked up to the
Altera Avalon SoC bus, and also provides a VGA-like text frame buffer.
Although it is compiled as a single device driver, it actually
implements a number of different device nodes exporting various
aspects of this multi-function device to userspace:
- Simple memory-mapped driver for the MTL 24-bit pixel frame buffer.
- Simple memory-mapped driver for the MTL control register set.
- Simple memory-mapped driver for the MTL text frame buffer.
- syscons attachment for the MTL text frame buffer.
This driver attaches directly to Nexus as is common for SoC device
drivers, and for the time being is considered BERI-specific, although
in principle it might be used with other hard and soft cores on
Altera FPGAs.
Control registers, including touchscreen input, are simply memory
mapped; in the future it would be desirable to hook up a more
conventional device node that can stream events, support kqueue(2)/
poll(2)/select(2), etc.
This is the first use of syscons on MIPS, as far as I can tell, and
there are some loose ends, such as an inability to use the hardware
cursor. More fundamentally, it appears that syscons(4) assumes that
either a host is PC-like (i386, amd64) *or* it must be using a
graphical frame buffer. While the MTL supports a graphical frame
buffer, using the text frame buffer is preferable for console use.
Fixing this issue in syscons(4) requires non-trivial changes, as the
text frame buffer support assumes that direct memory access can be
done to the text frame buffer without using bus accessor methods,
which is not the case on MIPS. As a workaround for this, we instead
double-buffer and pretend to be a graphical frame buffer exposing
text accessor methods, leading to some quirks in syscons behaviour.
Sponsored by: DARPA, AFRL
The driver attempts to support all documented parts, but has only been
tested with the 512Mbit part on the Terasic DE4 FPGA board. It should be
trivial to adapt the driver's attach routine to other embedded boards
using with any parts in the family.
Also import isfctl(8) which can be used to erase sections of the flash.
Sponsored by: DARPA, AFRL
which presents a UART-like interface over the Avalon bus that can be
addressed over JTAG. This IP core proves extremely useful, allowing us to
connect trivially to the FreeBSD console over JTAG for FPGA-embedded hard
and soft cores. As interrupts are optionally configured for this soft
core, we support both interrupt-driven and polled modes of operation,
which must be selected using device.hints. UART instances appear in /dev
as ttyu0, ttyu1, etc.
However, it also contains a number of quirks, which make it difficult to
tell when JTAG is connected, and some buffering issues. We work around
these as best we can, using various heuristics.
While the majority of this device driver is not only not BERI-specific,
but also not MIPS-specific, for now add its defines in the BERI files
list, as the console-level parts are aware of where the first JTAG UART
is mapped on Avalon, and contain MIPS-specific address translation, to
use before Newbus and device.hints are available.
Sponsored by: DARPA, AFRL
which can be synthesised in Altera FPGAs. An altera_sdcardc device
probes during the boot, and /dev/altera_sdcard devices come and go as
inserted and removed. The device driver attaches directly to the
Nexus, as is common for system-on-chip device drivers.
This IP core suffers a number of significant limitations, including a
lack of interrupt-driven I/O -- we must implement timer-driven polling,
only CSD 0 cards (up to 2G) are supported, there are serious memory
access issues that require the driver to verify writes to memory-mapped
buffers, undocumented alignment requirements, and erroneous error
returns. The driver must therefore work quite hard, despite a fairly
simple hardware-software interface. The IP core also supports at most
one outstanding I/O at a time, so is not a speed demon.
However, with the above workarounds, and subject to performance
problems, it works quite reliably in practice, and we can use it for
read-write mounts of root file systems, etc.
Sponsored by: DARPA, AFRL
CPU cores on Altera FPGAs. The device driver allows memory-mapped devices
on Altera's Avalon SoC bus to be exported to userspace via device nodes.
device.hints directories dictate device name, permissible access methods,
physical address and length, and I/O alignment. Devices can be accessed
using read(2)/write(2), but also memory mapped in userspace using mmap(2).
Devices attach directly to the Nexus, as is common for embedded device
drivers; in the future something more mature might be desirable. There is
currently no facility to support directing device-originated interrupts to
userspace.
In the future, this device driver may be renamed to socgen(4), as it can
in principle also be used with other system-on-chip (SoC) busses, such as
Axi on ASICs and FPGAs. However, we have only tested it on Avalon busses
with memory-mapped ROMs, frame buffers, etc.
Sponsored by: DARPA, AFRL
1) It is not useful to call "devfs_clear_cdevpriv()" from
"d_close" callbacks, hence for example read, write, ioctl and
so on might be sleeping at the time of "d_close" being called
and then then freed private data can still be accessed.
Examples: dtrace, linux_compat, ksyms (all fixed by this patch)
2) In sys/dev/drm* there are some cases in which memory will
be freed twice, if open fails, first by code in the open
routine, secondly by the cdevpriv destructor. Move registration
of the cdevpriv to the end of the drm open routines.
3) devfs_clear_cdevpriv() is not called if the "d_open" callback
registered cdevpriv data and the "d_open" callback function
returned an error. Fix this.
Discussed with: phk
MFC after: 2 weeks
r238211:
Support TARGET_ARCH=armv6 and TARGET_ARCH=armv6eb
This adds a new TARGET_ARCH for building on ARM
processors that support the ARMv6K multiprocessor
extensions. In particular, these processors have
better support for TLS and mutex operations.
This mostly touches a lot of Makefiles to extend
existing patterns for inferring CPUARCH from ARCH.
It also configures:
* GCC to default to arm1176jz-s
* GCC to predefine __FreeBSD_ARCH_armv6__
* gas to default to ARM_ARCH_V6K
* uname -p to return 'armv6'
* make so that MACHINE_ARCH defaults to 'armv6'
It also changes a number of headers to use
the compiler __ARM_ARCH_XXX__ macros to configure
processor-specific support routines.
Submitted by: Tim Kientzle <kientzle@freebsd.org>
- remove extra dynamic variable initializations;
- restore (4BSD) and implement (ULE) hogticks variable setting;
- make sched_rr_interval() more tolerant to options;
- restore (4BSD) and implement (ULE) kern.sched.quantum sysctl, a more
user-friendly wrapper for sched_slice;
- tune some sysctl descriptions;
- make some style fixes.
support for only the first port, but the CP2105 can have multiple ports.
Although this allowed the first port to mostly work on multi port devices,
there could be issues with this arrangement.
Update the man page to reflect support for both ports and the CP2105.
Many thanks to Silicon Labs (www.silabs.com) for providing a CP2105-EK
dev board for testing.
MFC after: 2 weeks
subdevice ahciem. Emulate SEMB SES device from AHCI LED interface to expose
it to users in form of ses(4) CAM device. If we ever see AHCI controllers
supporting SES of SAF-TE over I2C as described by specification, they should
fit well into this new picture.
Sponsored by: iXsystems, Inc.
list of supported devices with the union of:
NetBSD src/sys/dev/usb/uslsa.c 1.18
OpenBSD src/sys/dev/usb/uslcom.c 1.24
Linux source/drivers/usb/serial/cp210x.c HEAD
Remove duplicate JABLOTRON PC60B entry.
Note that some of the devices added here are multi-port devices. The
uslcom(4) driver currently only supports the first port on such devices.
Update the man page to reflect the full list of supported devices.
Remove two caveats from the CAVEATS section, as both listed caveats no
longer apply. Add a caveat about multi-port devices.
MFC after: 2 weeks
deprecated sysinstall(8). NOTE: WITH_BSDCONFIG is currently required.
Submitted by: Devin Teske (dteske), Ron McDowell <rcm@fuzzwad.org>
Reviewed by: Ron McDowell <rcm@fuzzwad.org>
Approved by: Ed Maste (emaste)
Asus laptops. It is alike to acpi_asus(4), but uses WMI interface instead
of separate ACPI device.
On Asus EeePC T101MT netbook it allows to handle hotkeys and on/off WLAN,
Bluetooth, LCD backlight, camera, cardreader and touchpad.
On Asus UX31A ultrabook it allows to handle hotkeys, on/off WLAN, Bluetooth,
Wireless LED, control keyboard backlight brightness, monitor temperature
and fan speed. LCD brightness control doesn't work now for unknown reason,
possibly requiring some video card initialization.
Sponsored by: iXsystems, Inc.
