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
value of capability databases, since it's not really obvious how a colon
can be escaped, and a pointer to the getcap(3) manpage for more details.
Triggered by: a question by Ceri on -questions
seperate the short name and the long name. This was present for most
but not all entries. Because the parsing doesn't reject unrecognized
entries, this didn't cause failures, but it wasn't strictly correct.
Submitted by: Martin Faxer <gmh003532@brfmasthugget.se>
MFC after: 2 weeks
distinction between the OS copyright message and the message displayed
gratuitously to each user at login. Because, well, they may be
different, among other things, and boy can a copyright message each
login consume some screen space. If people really want to do this,
they can copy /COPYRIGHT to /etc/COPYRIGHT.
Submitted by: Anders Andersson <anders@codefactory.se>
for a while, but a recent email to -stable suggests it should be spelled
out as the documentation of "password_format" is sparse.
Also add a `des_users' entry.
Submitted by: Sean O'Connell <sean@stat.Duke.EDU>
"passwordtime" is what passwd(1) has actually been using. I suspect
passwordperiod was the original intent. I can't figure-out which,
if either, BSDi uses. If anyone knows...
to be written to /etc.
The only essential change is in paths.h, so any third-party software
written correctly will pick it up in the next rebuild.
Reviewed by: the committers list (actually an old version)
man(1) will utilize manpath(1) if MANPATH is unset in the environment,
and with our existing manpath.config it is enough to find the X11
pages among others.
PR: 8587
Submitted by: Marc Slemko <marcs@znep.com>
original contents of the file preserved as examples for administrators
that need to enable them.
Also add a comment to the examples pointing out that the authentication
functionality is largely unused and requires rebuilding libutil.
Reviewed by: jkh
is not set to zero, only the soft limit. This means that non-root
processes started from /etc/rc* can explicitly raise the coredump limit
if they wish.
from /etc/rc, including inetd and it's children, stuff from
/usr/local/etc/rc.d (eg: squid, apache). The default limits are causing
a lot of problems including things like fsck failing on large disks.
I hope I've understood the quirks of the override mechanism properly.
Among bumping several limits, most interesting thing is that
Apache requires than "filesize=64M" restriction must be removed.
I think it is due to mmap() usage in apache, but I am not shure.
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
