| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
reference files to match the corresponding source.
MFC after: 3 days
|
| |
|
|
|
|
| |
MFC after: 1 month
|
|
|
|
| |
MFC after: 1 month
|
| |
|
| |
|
|
|
|
| |
No idea where this came from
|
|
|
|
|
|
|
| |
More graciously handle processing messages and watch events inline prior
to threads being up and running.
MFC after: 1 month
|
|
|
|
| |
in a commit message.
|
|
|
|
| |
a few days ago.
|
|
|
|
| |
MFC after: 1 week
|
| |
|
|
|
|
|
|
|
| |
interrupts from them. This should be more generalized, but is
sufficient for now.
Submitted by: Hans Petter Selasky
|
|
|
|
| |
Submitted by: Hans Petter Selasky
|
|
|
|
|
|
|
| |
place to add this connection, since the interrupt is for a GPIO pin,
but since we have no alternative at the moment...
Submitted by: Hans Petter Selasky
|
|
|
|
|
|
|
| |
since the 'cp_time' symbol doesn't exist in recent kernels. This fixes
iostat and vmstat on crash dumps.
MFC after: 1 week
|
|
|
|
|
|
|
|
|
|
| |
'kern.cp_time'. For a live kernel it uses the sysctl. For a crashdump,
it first checks to see if the kernel has a 'cp_time' global symbol. If
it does, it uses that. If that doesn't work, when it uses the recently
added kvm_getmaxcpu(3) and kvm_getpcpu(3) routines to walk all the CPUs
and sum up their counters.
MFC after: 1 week
|
|
|
|
|
|
|
| |
we free memory from underneath them.
This fixes an occasional panic I've been seeing in softclock() where a bad
pointer would be encountered when pushing DTrace hard.
|
|
|
|
| |
MFC after: 1 week
|
|
|
|
|
|
| |
kvm_getmaxcpu() and kvm_getpcpu().
MFC after: 1 week
|
|
|
|
|
|
|
| |
already define _KERNEL to get to this and I'm about to add hooks to
libkvm to access per-CPU data.
MFC after: 1 week
|
|
|
|
|
|
|
|
|
|
| |
The PCM's sound.h file only seems to include <sys/tty.h>, because
channel_if seems to require selinfo. Just replace it with
<sys/selinfo.h>.
There's no real problem with including <sys/tty.h> here, even with
MPSAFE TTY, but <sys/tty.h> is something that should be used by the TTY
layer, its driver and code that integrated it with the process tree.
|
|
|
|
| |
Requested by: many
|
|
|
|
|
|
|
|
|
|
|
| |
32-bit compat libs on amd64 since -march=k8 may generate instructions
that are not implemented on Intel EM64T processors. Instead, use
a simpler set of default flags that should work on all amd64-capable
CPUs.
PR: amd64/113111
Submitted by: NIIMI Satoshi sa2c of sa2c.net
MFC after: 1 week
|
|
|
|
|
|
|
|
| |
instead of QUEUE_DIRTY.
Tested by: pho
Reviewed by: attilio
MFC after: 3 days
|
|
|
|
| |
MFC after: 1 month
|
|
|
|
| |
MFC after: 1 month
|
|
|
|
| |
MFC after: 1 month
|
|
|
|
| |
MFC after: 1 month
|
|
|
|
| |
Tested by: Jonathan Lee <spamtrap at tczyhatczsche dot eu>
|
| |
|
| |
|
|
|
|
|
|
| |
even in the !defined(XEN) case
MFC after: 1 month
|
|
|
|
| |
for load instructions with direct or indirect offsets.
|
|
|
|
| |
This is roughly from sys/net/bpf_filter.c r1.12 and r1.14.
|
| |
|
|
|
|
| |
- Update copyrights and fix style(9).
|
|
|
|
| |
it shouldn't be used.
|
|
|
|
|
|
| |
sc->sc_isize might have changed.
MFC after: 3 days
|
|
|
|
|
|
| |
is Physical Minimum.
MFC after: 3 days
|
|
|
|
|
|
| |
commit.
Sponsored by: Nokia
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
corresponding USAGE should be skipped as well.
For example, below is a report desc fragment of some mouse:
COLLECTION
...
USAGE TWHEEL
FEATURE ...
...
USAGE WHEEL
INPUT ...
...
END COLLECTION
"USAGE TWHEEL" should be consumed after the FEATURE item is skipped,
otherwise, the INPUT item will be assigned to "USAGE TWHEEL" later,
other than "USAGE WHEEL".
Tested by: Grzegorz Blach
PR: usb/125941
|
|
|
|
|
|
|
|
|
| |
In order to CATER this, DDB buffered output can be choosen at compile
time through the option DDB_BUFR_SIZE=nbytes where nbytes choose the size
of the buffer (suggested size is 128 bytes), which should be manually
specified in any interested config file.
Sponsored by: Nokia
|
|
|
|
|
|
|
| |
Tested by: Merritt Draney, Brian Cox
PR: kern/123224
PR: kern/123510
MFC after: 3 days
|
| |
|
| |
|
|
|
|
|
|
|
| |
file local static globals which would be folded onto the same name
with the V_ macros.
Reviewed by: kris, brooks, simon
|
|
|
|
|
|
|
| |
now optionally exists.
Reviewed by: dfr
MFC after: 3 days
|
|
|
|
|
|
| |
(Handsfree interface)
I'll port the part to new tty layer after it has committed and
if I have spare time.
|