o List all devices FreeBSD supports (more on the way)
o Sort the list of supported devices
o Note this was introduced with FreeBSD 7.0
o Include the FreeBSD configuration synopsis
o Bump the man page date
o Put $FreeBSD$ where all the other usb man pages have it.
And add to build.
too, so, instead of descending to the i386 directory, we add some magic to
the parent Makefile.
These man pages refer to drivers that I'm aware that work on amd64. Most
likely there are more, but I'll deal with them later.
Approved by: brueffer, philip, takawata
The last half year I've been working on a replacement TTY layer for the
FreeBSD kernel. The new TTY layer was designed to improve the following:
- Improved driver model:
The old TTY layer has a driver model that is not abstract enough to
make it friendly to use. A good example is the output path, where the
device drivers directly access the output buffers. This means that an
in-kernel PPP implementation must always convert network buffers into
TTY buffers.
If a PPP implementation would be built on top of the new TTY layer
(still needs a hooks layer, though), it would allow the PPP
implementation to directly hand the data to the TTY driver.
- Improved hotplugging:
With the old TTY layer, it isn't entirely safe to destroy TTY's from
the system. This implementation has a two-step destructing design,
where the driver first abandons the TTY. After all threads have left
the TTY, the TTY layer calls a routine in the driver, which can be
used to free resources (unit numbers, etc).
The pts(4) driver also implements this feature, which means
posix_openpt() will now return PTY's that are created on the fly.
- Improved performance:
One of the major improvements is the per-TTY mutex, which is expected
to improve scalability when compared to the old Giant locking.
Another change is the unbuffered copying to userspace, which is both
used on TTY device nodes and PTY masters.
Upgrading should be quite straightforward. Unlike previous versions,
existing kernel configuration files do not need to be changed, except
when they reference device drivers that are listed in UPDATING.
Obtained from: //depot/projects/mpsafetty/...
Approved by: philip (ex-mentor)
Discussed: on the lists, at BSDCan, at the DevSummit
Sponsored by: Snow B.V., the Netherlands
dcons(4) fixed by: kan
Now we have a single /dev/snp device node, which can be opened by
watch(8) multiple times. Even though snp(4) will be dead as of next
week, it's nice having this in SVN, because:
- We may want to MFC it to RELENG_7.
- By the time we fix snp(4) again, it's already there, existing watch(8)
binaries should already work.
Just like bpf(4), I'm adding a symlink from snp0 to snp to remain binary
compatible.
bpf(4) now uses cdevpriv to distinguish multiple file descriptors, where
it used to be implemented using device cloning. Ports like libpcap
properly detect the change in their configure scripts, but it doesn't
hurt to increase __FreeBSD_version.
While there, change the bpf(4) manual page to refer to /dev/bpf instead
of /dev/bpfN.
Requested by: mlaier
This driver supports GW3887 based chipsets and works on
x86/powerpc/sparc64. You need upgtfw kernel module before loading
upgt(4). Please see the manpage.
Obtained from: OpenBSD
features of CPUs like reading/writing machine-specific registers,
retrieving cpuid data, and updating microcode.
- Add cpucontrol(8) utility, that provides userland access to
the features of cpuctl(4).
- Add subsequent manpages.
The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX
is created for each cpu present in the systems. The pseudo-device minor
number corresponds to the cpu number in the system. The cpuctl(4) pseudo-
device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID
and UPDATE. The first pair alows the caller to read/write machine-specific
registers from the correspondent CPU. cpuid data could be retrieved using
the CPUID call, and microcode updates are applied via UPDATE.
The permissions are inforced based on the pseudo-device file permissions.
RDMSR/CPUID will be allowed when the caller has read access to the device
node, while WRMSR/UPDATE will be granted only when the node is opened
for writing. There're also a number of priv(9) checks.
The cpucontrol(8) utility is intened to provide userland access to
the cpuctl(4) device features. The utility also allows one to apply
cpu microcode updates.
Currently only Intel and AMD cpus are supported and were tested.
Approved by: kib
Reviewed by: rpaulo, cokane, Peter Jeremy
MFC after: 1 month
msleep/mtx_sleep or the various cv_*wait*() routines. Currently, the
"unlock" behavior of PDROP and cv_wait_unlock() with Giant is not
permitted as it is will be confusing since Giant is fully unrecursed and
unlocked during a thread sleep.
This is handy for subsystems which wish to allow unlocked drivers to
continue to use Giant such as CAM, the new TTY layer, and the new USB
stack. CAM currently uses a hack that I told Scott to use because I
really didn't want to permit this behavior, and the TTY and USB patches
both have various patches to permit this.
MFC after: 2 weeks
yank it's description; likewise for the FIRMWARE_WAIT flag to firmware_put.
For the record, the last commit was to cleanup various mistakes and correct
the example of embedding to reflect the npe firmware now being distributed
with the system.
describes the minimum versions of each feature and each chipset type
supported by this driver. Basically, unless you have a very modern
version of firmware on a Prism card, you won't be able to use these
cards for much on modern networks that have any kind of protection
enabled, except for the few WEP-only stranglers that appear at some
conferences...
MPSAFE patches on current@ and stable@. This driver also has a fundamental
issue in that it sleeps when sending commands to the card including in the
if_init/if_start routines (which can be called from interrupt context). As
such, the driver shouldn't be working reliably even on 4.x.
and stable@. It also is a driver for an older non-802.11 wireless PC card
that is quite slow in comparison to say, wi(4). I know Warner wants this
driver axed as well.
current@ and stable@ for the locking patches. The driver can always be
revived if someone tests it.
This driver also sleeps in its if_init routine, so it likely doesn't really
work at all anyway in modern releases.
Adaptec RAID 2045
Adaptec RAID 2405
Adaptec RAID 2445
Adaptec RAID 2805
Without this change these devices are supported by the driver's family
support, but they then appear as "Adaptec RAID Controller" in boot
messages and the dev.aac.0.%desc sysctl.
description: TASKQUEUE_FAST_DEFINE(9), TASKQUEUE_FAST_DEFINE_THREAD(9),
taskqueue_create_fast(9). They deal with taskqueues intended for use
in fast interrupt handlers.
Approved by: cognet (mentor)
Reviewed by: keramida
path relative to /usr/include. It looks much better anyway.
Instead of referencing "socket", which is bogus, reference
'sys/socket.h', which is what should be placed here from
the beggining.
Suggested by: maxim
documents away from being public accessible. Replace link to
the Bluetooth specification document with the document name.
Pointed out by: SoftLover < slserg at uic dot tula dot ru >
MFC after: 3 days
parts relied on the now removed NET_NEEDS_GIANT.
Most of I4B has been disconnected from the build
since July 2007 in HEAD/RELENG_7.
This is what was removed:
- configuration in /etc/isdn
- examples
- man pages
- kernel configuration
- sys/i4b (drivers, layers, include files)
- user space tools
- i4b support from ppp
- further documentation
Discussed with: rwatson, re
NET_NEEDS_GIANT. netatm has been disconnected from the build for ten
months in HEAD/RELENG_7. Specifics:
- netatm include files
- netatm command line management tools
- libatm
- ATM parts in rescue and sysinstall
- sample configuration files and documents
- kernel support as a module or in NOTES
- netgraph wrapper nodes for netatm
- ctags data for netatm.
- netatm-specific device drivers.
MFC after: 3 weeks
Reviewed by: bz
Discussed with: bms, bz, harti
Even though single linked lists allow items to be removed at constant time
(when the previous element is known), the queue macro's don't allow this.
Implement new REMOVE_NEXT() macro's. Because the REMOVE() macro's also
contain the same code, make it call REMOVE_NEXT().
The OpenBSD version of SLIST_REMOVE_NEXT() needs a reference to the list
head, even though it is unused. We'd better mimic this. The STAILQ version
also needs a reference to the list. This means the prototypes of both
macro's are the same.
Approved by: philip (mentor)
PR: kern/121117
To preserve the existing behavior of etc/rc.d/netif, add code to wait
up to if_up_delay seconds (30 seconds by default) for a default route to
be configured if there are any dhcp interfaces. This should be extended
to test that the interface is actually up.
X-MFC after:
issue in termios.4, ttydefaults.h does not exist in /usr/include
but in /usr/include/sys.
MFC after: 3 days
Submitted by: Ed Schouten (ed at 80386 dot nl)
support for VMFS_ALIGNED_SPACE, which requests the allocation of an
address range best suited to superpages. The old options TRUE and FALSE
are mapped to VMFS_ANY_SPACE and VMFS_NO_SPACE, so that there is no
immediate need to update all of vm_map_find(9)'s callers.
While I'm here, correct a misstatement about vm_map_find(9)'s return
values in the man page.
more wlans_<ifn> and create_args_<ifn>
Add documentation for these variants and generally update the wireless
device example.
There is are very short lived shim from vaps_<ifn> which produces
a warning and vap_create_<ifn> which does not. Misuse the MFC
notification service to remind me to remove them.
MFC after: 3 weeks
Note this includes changes to all drivers and moves some device firmware
loading to use firmware(9) and a separate module (e.g. ral). Also there
no longer are separate wlan_scan* modules; this functionality is now
bundled into the wlan module.
Supported by: Hobnob and Marvell
Reviewed by: many
Obtained from: Atheros (some bits)
mode at boot time. Multiple profiles can be started at the same time.
The whole idea is very similar to the ppp rc script.
Document Bluetooth knobs in rc.conf(5)
MFC after: 1 week
commands can be written to /dev/psm%d and status can be read back from it.
- Reflect the change in psm(4) and bump version for ports.
MFC after: 1 week
buffer kernel descriptors, which is used to allow the buffer
currently in the BPF "store" position to be assigned to userspace
when it fills, even if userspace hasn't acknowledged the buffer
in the "hold" position yet. To implement this, notify the buffer
model when a buffer becomes full, and check that the store buffer
is writable, not just for it being full, before trying to append
new packet data. Shared memory buffers will be assigned to
userspace at most once per fill, be it in the store or in the
hold position.
This removes the restriction that at most one shared memory can
by owned by userspace, reducing the chances that userspace will
need to call select() after acknowledging one buffer in order to
wait for the next buffer when under high load. This more fully
realizes the goal of zero system calls in order to process a
high-speed packet stream from BPF.
Update bpf.4 to reflect that both buffers may be owned by userspace
at once; caution against assuming this.
per-profile variables of the form ppp_<profile>_unit. No ppp_unit
variable is supported since tying the same unit to more than one profile
won't work.
PR: conf/122127
MFC after: 1 week
to _ when evaluating ppp_<profile>_nat and ppp_<profile>_mode. Document
the per-profile variables.
PR: conf/121452, conf/122127 (partial)
MFC after: 1 week
