Off by default, build behaves normally.
WITH_META_MODE we get auto objdir creation, the ability to
start build from anywhere in the tree.
Still need to add real targets under targets/ to build packages.
Differential Revision: D2796
Reviewed by: brooks imp
device is an active kernel console and "off" otherwise. This is designed to
allow serial-booting x86 systems to provide a login prompt on the serial line
by default without providing one on all systems by default.
Comments and suggestions by: grehan, dteske, jilles
MFC after: 1 month
I've noticed various terminal emulators that need to obtain a sane
default termios structure use very complex `hacks'. Even though POSIX
doesn't provide any functionality for this, extend our termios API with
cfmakesane(3), which is similar to the commonly supported cfmakeraw(3),
except that it fills the termios structure with sane defaults.
Change all code in our base system to use this function, instead of
depending on <sys/ttydefaults.h> to provide TTYDEF_*.
The ttyslot() function was originally part for SUSv1, marked LEGACY in
SUSv2 and removed later on. This function only makes sense when using
utmp(5), because it was used to determine the offset of the record for
the controlling TTY. It makes little sense to keep it here, because the
new utmpx file format doesn't index based on TTY slots.
Just like bin/ and sbin/, I think setting WARNS to the highest value
possible will make it more attractive for people to fix warnings.
- The WARNS variable is set in the Makefile in the directory of the
application itself, making it more likely that it will be removed out
of curiosity to see what happens.
- New applications will most likely build with WARNS=6 out of the box,
because the author would more likely fix the warnings during
development than lower WARNS.
Unfortunately almost all apps in libexec require a lowered value of
WARNS.
as the source of defaults for terminal device parameters.
- Do duplucate code reduction and simplification enabled by
the above.
Reviewed by: green
MFC after: 1 month
A PPP login program is started _automatically_ (i.e., without
human intervention) even with the "pl" capability unset, as soon
as a PPP frame is detected. But with "pl" set, a PPP login program
is started independently of the result of PPP detection (which is
rendered unnecessary then,) i.e. _unconditionally_.
information could only be gleaned from the the tty descriptor itself
was neglected, so never did the tty's default settings get copied from
the kernel. Specifically, this caused all manner of ctrl-keys to not
work. Fix this by calling dogettytab() in all the proper places, and
retrieving the terminfo temporarily in dogettytab().
- Use .Va, not .Em, to mark up variable-like identifiers
(capability and database entry names.)
- Stop abusing .Tn (trademark) to emphasize general phrases.
- Spot unmarked capability references.
- Add a missing line break.
Discussed with: ru
MFC after: 1 week
capabilities:
- Mark up capability identifiers.
- Don't squeeze much text into the capability table given the options
will be described below in detail.
- Keep the capability table sorted.
- Use a consistent term for a PPP login program.
MFC after: 1 week
- Initialize "rval", which would be used uninitialized
if al or pl options were set.
- Don't pass an empty string to login(1) as a user name
(this could be triggered by entering a name and then killing it
with backspace or ^U.)
- Don't loop endlessly if the al option specifies a bogus (i.e.,
not alphanumeric) auto-login name.
- Don't pass a bogus user name to login(1) if a good name were
entered and then killed with ^U.
- Exit with status 0, not 1, on receiving an EOF character,
since it's not a error condition.
MFC after: 1 week
in question is PPP-only line, i.e. no PPP-sequence detection is necessary and
PPP login program referenced by `pp' should be started automatically instead of
login(1)
Feature suggested and sponsored by: United Networks of Ukraine
No reply from: re
MFC after: 2 weeks
