to char-cell based vga(4) driver, and fully compatible with existing
apps like XFree86. Currently it supports 80x25, 80x30, 80x40 and 80x50
text modes using emulation. You can enable it by specifying `options
VGA_RASTERCONSOLE' in your kernel config file.
Note that displaying multilingual text doesn't work yet. Necessary
code is already there, but userland stuff and some functionality isn't
ready for prime time yet. I'm working on them.
Define an attribute for each crypto algorithm, and use that attribute
to select the files that implement the algorithm.
* Give the "wlan" attribute a dependency on the "arc4" attribute.
* Give the "cgd" pseudo-device the "des", "blowfish", "cast128", and
"rijndael" attributes.
* Use the new attribute-as-option-dependencies feature of config(8) to
give the IPSEC_ESP option dependencies on the "des", "blowfish", "cast128",
and "rijndael" attributes.
netinet/files.ipfilter, etinet/files.netinet, netinet6/files.netinet6,
and netinet6/files.netipsec.
XXX There are still a few stragglers in conf/files, which are entangled
with other network protocols.
"scsi_core". Make all the files previously selected by the "scsi"
attribute selected by the "scsi_core" attribute. Give the "scsibus"
device the "scsi_core" attribute.
- Split if_fmv.c into MI/MD part and add ISA-PnP attachment for FMV-183.
(XXX FMV-184 is not tested. It would require extra media-select functions..)
- Fix probe functions of fmv_isa so that FMV-181A/182A will also match.
Fixes port-i386/9476.
- Eliminate wi_hostap.c since most of the code are duplicated with
net/if_ieee80211subr.c
- Station for Infrastructure network and IBSS also use service functions
as much as possible to be consistent with other wireless drivers.
Now WEP works for station/ibss/hostap.
Setup sequence obtained from Krups OFW with some CyberPro-specific
magic from Linux driver. The driver still has a lot of hardcoded
stuff, but it is useful enough to bring up wscons on netwinder.
XXX: Proper console attachment needs to be written (the driver was
originally developed on sparc, where our approach to attaching console
is totally different).
Caveat emptor!
This merge changes the device switch tables from static array to
dynamically generated by config(8).
- All device switches is defined as a constant structure in device drivers.
- The new grammer ``device-major'' is introduced to ``files''.
device-major <prefix> char <num> [block <num>] [<rules>]
- All device major numbers must be listed up in port dependent majors.<arch>
by using this grammer.
- Added the new naming convention.
The name of the device switch must be <prefix>_[bc]devsw for auto-generation
of device switch tables.
- The backward compatibility of loading block/character device
switch by LKM framework is broken. This is necessary to convert
from block/character device major to device name in runtime and vice versa.
- The restriction to assign device major by LKM is completely removed.
We don't need to reserve LKM entries for dynamic loading of device switch.
- In compile time, device major numbers list is packed into the kernel and
the LKM framework will refer it to assign device major number dynamically.
from if_ieee80211subr.c, since "wi" devices implement the 802.11
protocol in firmware (for the most part). So, remove the wlan attribute,
which saves a fair bit of kernel text.
counters. These counters do not exist on all CPUs, but where they
do exist, can be used for counting events such as dcache misses that
would otherwise be difficult or impossible to instrument by code
inspection or hardware simulation.
pmc(9) is meant to be a general interface. Initially, the Intel XScale
counters are the only ones supported.
compile directory is not under /usr/src/sys (i.e. when 'S' is not
'../../../..'). Pointed out by Robert Elz in PR 17384.
Thanks again to Andrew Brown for figuring out how to rip .depend apart.
the block comment at the top of the file:
This module provides kernel support for testing network
throughput from the perspective of the kernel. It is
similar in spirit to the classic ttcp network benchmark
program, the main difference being that with kttcp, the
kernel is the source and sink of the data.
Testing like this is useful for a few reasons:
1. This allows us to know what kind of performance we can
expect from network applications that run in the kernel
space, such as the NFS server or the NFS client. These
applications don't have to move the data to/from userspace,
and so benchmark programs which run in userspace don't
give us an accurate model.
2. Since data received is just thrown away, the receiver
is very fast. This can provide better exercise for the
sender at the other end.
3. Since the NetBSD kernel currently uses a run-to-completion
scheduling model, kttcp provides a benchmark model where
preemption of the benchmark program is not an issue.
There is a companion "kttcp" user program which uses the kttcp
pseudo-device.
Largely written by Frank van der Linden, with some modifications
from me.
