Serialize write() calls on TTYs.

Just like the old TTY layer, the current MPSAFE TTY layer does not make
any attempt to serialize calls of write(). Data is copied into the
kernel in 256 (TTY_STACKBU

Serialize write() calls on TTYs.

Just like the old TTY layer, the current MPSAFE TTY layer does not make
any attempt to serialize calls of write(). Data is copied into the
kernel in 256 (TTY_STACKBUF) byte chunks. If a write() call occurs at
the same time, the data may interleave. This is especially likely when
the TTY starts blocking, because the output queue reaches the high
watermark.

I've implemented this by adding a new flag, TTY_BUSY_OUT, which is used
to mark a TTY as having a thread stuck in write(). Because I don't want
non-blocking processes to be possibly blocked by a sleeping thread, I'm
still allowing it to bypass the protection. According to this message,
the Linux kernel returns EAGAIN in such cases, but I think that's a
little too restrictive:

http://kerneltrap.org/index.php?q=mailarchive/linux-kernel/2007/5/2/85418/thread

PR: kern/118287

show more ...

Don't leave the console TTY constantly open.

When we leave the console TTY constantly open, we never reset the
termios attributes. This causes output processing, echoing, etc. not to
be reset to the

Don't leave the console TTY constantly open.

When we leave the console TTY constantly open, we never reset the
termios attributes. This causes output processing, echoing, etc. not to
be reset to the proper values when going into single user mode after the
system has booted. It also causes nl-to-crnl-conversion not to take
place during shutdown, which causes a `staircase effect'.

This patch adds a new TTY flag, TF_OPENED_CONS, which is set when the
TTY is opened through /dev/console. Because the flags are only used by
the kernel and the pstat(8) utility, I've decided to renumber the TTY
flags. This shouldn't be an issue, because the TTY layer is not yet part
of a stable release.

Reported by: Mark Atkinson <atkin901 yahoo com>
Tested by: sepotvin

show more ...

Slightly improve the design of the TTY buffer.

The TTY buffers used the standard <sys/queue.h> lists. Unfortunately
they have a big shortcoming. If you want to have a double linked list,
but no tail

Slightly improve the design of the TTY buffer.

The TTY buffers used the standard <sys/queue.h> lists. Unfortunately
they have a big shortcoming. If you want to have a double linked list,
but no tail pointer, it's still not possible to obtain the previous
element in the list. Inside the buffers we don't need them. This is why
I switched to custom linked list macros. The macros will also keep track
of the amount of items in the list. Because it doesn't use a sentinel,
we can just initialize the queues with zero.

In its simplest form (the output queue), we will only keep two
references to blocks in the queue, namely the head of the list and the
last block in use. All free blocks are stored behind the last block in
use.

I noticed there was a very subtle bug in the previous code: in a very
uncommon corner case, it would uma_zfree() a block in the queue before
calling memcpy() to extract the data from the block.

show more ...

Use the proper flag to let kern.ttys be executed without Giant.

Pointed out by: jhb

Mark kern.ttys as MPSAFE.

sysctl now allows Giantless calls, so make kern.ttys use this. If it
needs Giant, it locks the proper TTY anyway.

Fix a corner case in my previous commit.

Even though there are not many setups that have absolutely no console
device, make sure a close() on a TTY doesn't dereference a null pointer.

Don't let /dev/console be revoked if the TTY below is being closed.

During startup some of the syscons TTY's are used to set attributes like
the screensaver and mouse options. These actions cause /d

Don't let /dev/console be revoked if the TTY below is being closed.

During startup some of the syscons TTY's are used to set attributes like
the screensaver and mouse options. These actions cause /dev/console to
be rendered unusable.

Fix the issue by leaving the TTY opened when it is used as the console
device.

Reported by: imp

show more ...

Let wchan names more closely match pre-MPSAFE TTY behaviour.

Right now the wchan strings "ttyinp" and "ttybgw" only differ one
character from the strings we used prior to MPSAFE TTY. Just rename the

Let wchan names more closely match pre-MPSAFE TTY behaviour.

Right now the wchan strings "ttyinp" and "ttybgw" only differ one
character from the strings we used prior to MPSAFE TTY. Just rename them
back to their pre-MPSAFE TTY counterparts.

Also rename "ttylck" to "ttymtx", which should make it more clear that a
process is blocked on the TTY mutex, not some other form of locking.

show more ...

MFH @ 186335

Further beautify the lock strings to be more pleasing to the eye and
self documenting within 6 characters.

Reviewed by: ed (older version)
Approved by: gnn (older version)

Remove spaces in wait object names to make top (1) output prettier and
unbreak scripts that examine ps (1) output.

Reviewed by: ed
Approved by: gnn (mentor)

Change ttyhook_register() second argument from thread to process pointer.
Thread was not really needed there, while previous ng_tty implementation
that used thread pointer had locking issues (using s

Change ttyhook_register() second argument from thread to process pointer.
Thread was not really needed there, while previous ng_tty implementation
that used thread pointer had locking issues (using sx while holding mutex).

show more ...

integrate from head@185615

Reduce the default baud rate of PTY's to 9600.

On RELENG_6 (and probably RELENG_7) we see our syscons windows and
pseudo-terminals have the following buffer sizes:

| LINE RAW CAN OUT IHIWT ILOWT OH

Reduce the default baud rate of PTY's to 9600.

On RELENG_6 (and probably RELENG_7) we see our syscons windows and
pseudo-terminals have the following buffer sizes:

| LINE RAW CAN OUT IHIWT ILOWT OHWT LWT COL STATE SESS PGID DISC
| ttyv0 0 0 0 7680 6720 2052 256 7 OCcl 1146 1146 term
| ttyp0 0 0 0 7680 6720 1296 256 0 OCc 82033 82033 term

These buffer sizes make no sense, because we often have much more output
than input, but I guess having higher input buffer sizes improves
guarantees of the system.

On MPSAFE TTY I just sent both the input and output buffer sizes to 7
KB, which is pretty big on a standard FreeBSD install with 8 syscons
windows and some PTY's. Reduce the baud rate to 9600 baud, which means
we now have the following buffer sizes:

| LINE INQ CAN LIN LOW OUTQ USE LOW COL SESS PGID STATE
| ttyv0 1920 0 0 192 1984 0 199 7 2401 2401 Oil
| pts/0 1920 0 0 192 1984 0 199 5631 1305 2526 Oi

This is a lot smaller, but for pseudo-devices this should be good
enough. You need to do a lot of punching to fill up a 7.5 KB input
buffer. If it turns out things don't work out this way, we'll just
switch to 19200 baud.

show more ...

Clamp the values of t_column to 5 digits in `pstat -t' and `show all ttys'.

We often run into these very high column numbers when we run curses
applications, because they don't print any newlines. T

Clamp the values of t_column to 5 digits in `pstat -t' and `show all ttys'.

We often run into these very high column numbers when we run curses
applications, because they don't print any newlines. This messes up the
table output of `pstat -t'. If these numbers get really high, they
aren't of any use to the reader anyway. Convert them to `99999' when
they run out of bounds.

show more ...

Reimplement the /dev/console device node.

One of the pieces of code that I had left alone during the development
of the MPSAFE TTY layer, was tty_cons.c. This file actually has two
different functio

Reimplement the /dev/console device node.

One of the pieces of code that I had left alone during the development
of the MPSAFE TTY layer, was tty_cons.c. This file actually has two
different functions:

- It contains low-level console input/output routines (cnputc(), etc).

- It creates /dev/console and wraps all its cdevsw calls to the
appropriate TTY.

This commit reimplements the second set of functions by moving it
directly into the TTY layer. /dev/console is now a character device node
that's basically a regular TTY, but does a lookup of `si_drv1' each time
you open it. d_write has also been changed to call log_console().
d_close() is not present, because we must make sure we don't revoke the
TTY after writing a log message to it.

Even though I'm not convinced this is in line with the future directions
of our console code, it is a good move for now. It removes recursive
locking from the top half of the TTY layer. The previous implementation
called into the TTY layer with Giant held.

I'm renaming tty_cons.c to kern_cons.c now. The code hardly contains any
TTY related bits, so we'd better give it a less misleading name.

Tested by: Andrzej Tobola <ato iem pw edu pl>,
Carlos A.M. dos Santos <unixmania gmail com>,
Eygene Ryabinkin <rea-fbsd codelabs ru>

show more ...

Fix spelling mistake in the last rev.

If we have getc_inject hooked then the outq buffer is inaccessible to the
driver so skip the drain rather than waiting indefinitely.

Reviewed by: ed

Import some improvements to the TTY code from the MPSAFE TTY branch.

- Change the ddb(4) commands to be more useful (by thompsa@):
- `show ttys' is now called `show all ttys'. This command will no

Import some improvements to the TTY code from the MPSAFE TTY branch.

- Change the ddb(4) commands to be more useful (by thompsa@):
- `show ttys' is now called `show all ttys'. This command will now
also display the address where the TTY data structure resides.
- Add `show tty <addr>', which dumps the TTY in a readable form.

- Place an upper bound on the TTY buffer sizes. Some drivers do not want
to care about baud rates. Protect these drivers by preventing the TTY
buffers from getting enormous. Right now we'll just clamp it to 64K,
which is pretty high, taking into account that these buffers are only
used by the built-in discipline.

- Only call ttydev_leave() when needed. Back in April/May the TTY
reference counting mechanism was a little different, which required us
to call ttydev_leave() each time we finished a cdev operation.
Nowadays we only need to call ttydev_leave() when we really mark it as
being closed.

- Improve return codes of read() and write() on TTY device nodes.

- Make sure we really wake up all blocked threads when the driver calls
tty_rel_gone(). There were some possible code paths where we didn't
properly wake up any readers/writers.

- Add extra assertions to prevent sleeping on a TTY that has been
abandoned by the driver.

- Use ttydev_cdevsw as a more reliable method to figure out whether a
device node is a real TTY device node.

Obtained from: //depot/projects/mpsafetty/...
Reviewed by: thompsa

show more ...

Don't forget to initialize `int error' in ttydev_open().

I've had some reports in the past that opening an already opened TTY
through, for example, /dev/tty can fail with random error codes. Looking

Don't forget to initialize `int error' in ttydev_open().

I've had some reports in the past that opening an already opened TTY
through, for example, /dev/tty can fail with random error codes. Looking
at ttydev_open(), I can see there is a way `error' is returned without
initialising it. Even though I haven't had any confirmation this fixes
the bug, I'll fix it anyway.

Reported by: Andrzej Tobola <ato iem pw edu pl>

show more ...

Fix a crash when calling tty_rel_free() while draining during closure.

Yesterday I got two reports of potential crashes, related to TTY
deallocation during device closure. When a thread is in TF_OPE

Fix a crash when calling tty_rel_free() while draining during closure.

Yesterday I got two reports of potential crashes, related to TTY
deallocation during device closure. When a thread is in TF_OPENCLOSE,
draining its output upon closure, we should not allow calls to
tty_rel_free() to happen at the same time. This could cause the TTY to
be torn down twice.

PR: kern/127561
Reported by: KOIE Hidetaka <koie suri co jp>
Discussed with: thompsa

show more ...

Introduce a hooks layer for the MPSAFE TTY layer.

One of the features that prevented us from fixing some of the TTY
consumers to work once again, was an interface that allowed consumers to
do the fo

Introduce a hooks layer for the MPSAFE TTY layer.

One of the features that prevented us from fixing some of the TTY
consumers to work once again, was an interface that allowed consumers to
do the following:

- `Sniff' incoming data, which is used by the snp(4) driver.

- Take direct control of the input and output paths of a TTY, which is
used by ng_tty(4), ppp(4), sl(4), etc.

There's no practical advantage in committing a hooks layer without
having any consumers. In P4 there is a preliminary port of snp(4) and
thompsa@ is busy porting ng_tty(4) to this interface. I already want to
have it in the tree, because this may stimulate others to work on the
remaining modules.

Discussed with: thompsa
Obtained from: //depot/projects/mpsafetty/...

show more ...

Fix minor TTY API inconsistency.

Unlike tty_rel_gone() and tty_rel_sess(), the tty_rel_pgrp() routine
does not unlock the TTY. I once had the idea to make the code call
tty_rel_pgrp() and tty_rel_se

Fix minor TTY API inconsistency.

Unlike tty_rel_gone() and tty_rel_sess(), the tty_rel_pgrp() routine
does not unlock the TTY. I once had the idea to make the code call
tty_rel_pgrp() and tty_rel_sess(), picking up the TTY lock once. This
turned out a little harder than I expected, so this is how it works now.

It's a lot easier if we just let tty_rel_pgrp() unlock the TTY, because
the other routines do this anyway.

show more ...

Make TIOCCONS use priv_check() instead of checking /dev/console permissions.

As discussed with Robert on IRC, checking the permissions on
/dev/console to see if we can call TIOCCONS could be unrelia

Make TIOCCONS use priv_check() instead of checking /dev/console permissions.

As discussed with Robert on IRC, checking the permissions on
/dev/console to see if we can call TIOCCONS could be unreliable. When we
run a chroot() without a devfs instance mounted inside, it won't
actually check the permissions on the device node inside the devfs
instance.

Using the already existing PRIV_TTY_CONSOLE for this seems like a better
idea.

Approved by: rwatson

show more ...

Implement pts(4) packet mode.

As reported by several users on the mailing lists, applications like
screen(1) fail to properly handle ^S and ^Q characters. This was because
MPSAFE TTY didn't implemen

Implement pts(4) packet mode.

As reported by several users on the mailing lists, applications like
screen(1) fail to properly handle ^S and ^Q characters. This was because
MPSAFE TTY didn't implement packet mode (TIOCPKT) yet. Add basic packet
mode support to make these applications work again.

Obtained from: //depot/projects/mpsafetty/...

show more ...