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
- Fix dates in 2008/2009 for Africa/Mauritius.
- Leap second notification for the end of 2008.
Approved by: bde (mentor, implicit), des
MFC after: 1 week
- Mauritius will have a DST experiment between 2008-11-01 and 2009-03-31.
- Add/Fix historical data for C-Eur, the SovietZone, Germany,
Bahamas, San Luis.
- Add information about West Para (America/Santarem)
- America/Eirunepe and America/Rio_Branco go to UTC-4
Approved by: bde (mentor, implicit), des
MFC after: 1 week
- Africa/Morocco will have DST in 2008.
- Asia/Choibalsan should be GMT+08:00.
- Asia/Pakistan will have DST in 2008.
Also set all the svn:eol-style properties to native.
Approved by: bde (mentor, implicit), des
MFC after: 1 week
Remove Theory, which isn't part of the zoneinfo module but came out
of /head/usr.sbin/zic (and isn't installed from there neither).
Approved by: bde (implicit)
MFC after: 1 week
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.
I've obtained a draft, <u:> is indeed equivalent to u (to my surprise),
and <th> sorts immediately after z.
The correct ordering is algorithmic (based on the EOR) and can not be
accurately represented as a table.
LOCALES list. Since no_NO was still in LOCALES, make tried to build the
corresponding .out files, but couldn't since the .src files were gone. I
did not notice this because I still had the old .out files in my .OBJDIR.
Thanks to kib@ for the heads-up.
makes sense to have them both link to no_NO.
In other cases (such as LC_TIME), they differ, and the correct solution
is to have no_NO link to nb_NO, rather than the other way around.o
MFC after: 2 weeks
and nn_NO, which are symlinked to no_NO.
The patch in the PR contained a number of errors apparently based on
(sometimes incorrect) pronunciation; for instance, v and w are
distinct letters and should be collated in that order, even if they
are pronounced the same, while <u:> should be collated with u, even
though it is often mispronounced as y. For lack of a solid reference,
I have taken sv_SE and simply changed the last three letters of the
alphabet.
PR: conf/51920
MFC after: 2 weeks
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...
The segfaults when using SSP seem to be a gcc bug, a patch is available
in the gcc bugzilla, and will be imported once it's committed
into the official gcc tree.
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.
