update paths; and include everything in the "base" distribution.
The "games" distribution being optional made sense when there were more
games and we had small disks; but the "games-like" games were moved into
the ports tree a dozen years ago and the remaining "utility-like" games
occupy less than 0.001% of my laptop's small hard drive. Meanwhile every
new user is confronted by the question "do you want games installed" when
they they try to install FreeBSD.
The next steps will be:
2. Removing punch card (bcd, ppt), phase-of-moon (pom), clock (grdc), and
caesar cipher (caesar, rot13) utilities. I intend to keep fortune, factor,
morse, number, primes, and random, since there is evidence that those are
still being used.
3. Merging src/games into src/usr.bin.
This change will not be MFCed.
Reviewed by: jmg
Discussed at: EuroBSDCon
Approved by: gjb (release-affecting changes)
user. Kqueue now saves the ucred of the allocating thread, to
correctly decrement the counter on close.
Under some specific and not real-world use scenario for kqueue, it is
possible for the kqueues to consume memory proportional to the square
of the number of the filedescriptors available to the process. Limit
allows administrator to prevent the abuse.
This is kernel-mode side of the change, with the user-mode enabling
commit following.
Reported and tested by: pho
Discussed with: jmg
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
This prevents unprivileged users to lock too much memory.
- Set memorylocked limit to 64Mb for daemon login class.
Some daemons such as amd(8) and watchdogd(8) calls mlockall(2) on
startup, they are run from init(8) which uses daemon login class.
- Set memorylocked limit to unlimited for root login class.
Suggested by: avg
Approved by: kib (mentor)
MFC after: 1 week
- update for getrlimit(2) manpage;
- support for setting RLIMIT_SWAP in login class;
- addition to the limits(1) and sh and csh limit-setting builtins;
- tuning(7) documentation on the sysctls controlling overcommit.
In collaboration with: pho
Reviewed by: alc
Approved by: re (kensmith)
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.
