History log of /freebsd/sys/kern/tty.c (Results 326 – 350 of 860)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 1d9c5696 01-Oct-2002 Juli Mallett <jmallett@FreeBSD.org>

Back our kernel support for reliable signal queues.

Requested by: rwatson, phk, and many others


# 1226f694 30-Sep-2002 Juli Mallett <jmallett@FreeBSD.org>

First half of implementation of ksiginfo, signal queues, and such. This
gets signals operating based on a TailQ, and is good enough to run X11,
GNOME, and do job control. There are some intricate p

First half of implementation of ksiginfo, signal queues, and such. This
gets signals operating based on a TailQ, and is good enough to run X11,
GNOME, and do job control. There are some intricate parts which could be
more refined to match the sigset_t versions, but those require further
evaluation of directions in which our signal system can expand and contract
to fit our needs.

After this has been in the tree for a while, I will make in kernel API
changes, most notably to trapsignal(9) and sendsig(9), to use ksiginfo
more robustly, such that we can actually pass information with our
(queued) signals to the userland. That will also result in using a
struct ksiginfo pointer, rather than a signal number, in a lot of
kern_sig.c, to refer to an individual pending signal queue member, but
right now there is no defined behaviour for such.

CODAFS is unfinished in this regard because the logic is unclear in
some places.

Sponsored by: New Gold Technology
Reviewed by: bde, tjr, jake [an older version, logic similar]

show more ...


# 71fad9fd 11-Sep-2002 Julian Elischer <julian@FreeBSD.org>

Completely redo thread states.

Reviewed by: davidxu@freebsd.org


Revision tags: release/4.6.2_cvs, release/4.6.2, release/4.6.1
# 9f189ade 18-Jul-2002 Julian Elischer <julian@FreeBSD.org>

Clear up confusion in ugly code. ^T gave wrong results for RSS.
I misinterpretted this code when changing it to handle threads.
(there are still issues here)
Submitted by: Ian Dowse <iedowse@maths.t

Clear up confusion in ugly code. ^T gave wrong results for RSS.
I misinterpretted this code when changing it to handle threads.
(there are still issues here)
Submitted by: Ian Dowse <iedowse@maths.tcd.ie>

show more ...


Revision tags: release/4.6.0_cvs
# e602ba25 29-Jun-2002 Julian Elischer <julian@FreeBSD.org>

Part 1 of KSE-III

The ability to schedule multiple threads per process
(one one cpu) by making ALL system calls optionally asynchronous.
to come: ia64 and power-pc patches, patches for gdb, test pro

Part 1 of KSE-III

The ability to schedule multiple threads per process
(one one cpu) by making ALL system calls optionally asynchronous.
to come: ia64 and power-pc patches, patches for gdb, test program (in tools)

Reviewed by: Almost everyone who counts
(at various times, peter, jhb, matt, alfred, mini, bernd,
and a cast of thousands)

NOTE: this is still Beta code, and contains lots of debugging stuff.
expect slight instability in signals..

show more ...


# 99568bca 20-Jun-2002 Ian Dowse <iedowse@FreeBSD.org>

Display the mutex name in the ^T status line if the selected thread
is blocked on a mutex. Prepend a '*' to distinguish this case as
is done in top(1).


# 7aa57dca 31-May-2002 Dag-Erling Smørgrav <des@FreeBSD.org>

Nit: kern.ttys is of type S,xtty, not S,tty.


# 6b658142 28-May-2002 Dag-Erling Smørgrav <des@FreeBSD.org>

Add some checks to prevent NULL dereferences.

Submitted by: jhay


# 6c533ac7 28-May-2002 Dag-Erling Smørgrav <des@FreeBSD.org>

Add NAI copyright.


# 1a149fcd 28-May-2002 Dag-Erling Smørgrav <des@FreeBSD.org>

Introduce struct xtty, used when exporting tty information to userland.
Make kern.ttys export a struct xtty rather than struct tty. Since struct
tty is no longer exposed to userland, remove the dev_

Introduce struct xtty, used when exporting tty information to userland.
Make kern.ttys export a struct xtty rather than struct tty. Since struct
tty is no longer exposed to userland, remove the dev_t / udev_t hack.

Sponsored by: DARPA, NAI Labs

show more ...


# 4b4c18f8 25-May-2002 Dag-Erling Smørgrav <des@FreeBSD.org>

ANSIfy (significant portions were already partly ANSIfied)


# b7457aab 25-May-2002 Dag-Erling Smørgrav <des@FreeBSD.org>

Remove register.


# dedf14f5 25-May-2002 Dag-Erling Smørgrav <des@FreeBSD.org>

Automated whitespace cleanup.


# e649887b 06-May-2002 Alfred Perlstein <alfred@FreeBSD.org>

Make funsetown() take a 'struct sigio **' so that the locking can
be done internally.

Ensure that no one can fsetown() to a dying process/pgrp. We need
to check the process for P_WEXIT to see if it

Make funsetown() take a 'struct sigio **' so that the locking can
be done internally.

Ensure that no one can fsetown() to a dying process/pgrp. We need
to check the process for P_WEXIT to see if it's exiting. Process
groups are already safe because there is no such thing as a pgrp
zombie, therefore the proctree lock completely protects the pgrp
from having sigio structures associated with it after it runs
funsetownlst.

Add sigio lock to witness list under proctree and allproc, but over
proc and pgrp.

Seigo Tanimura helped with this.

show more ...


# f1320723 01-May-2002 Alfred Perlstein <alfred@FreeBSD.org>

Redo the sigio locking.

Turn the sigio sx into a mutex.

Sigio lock is really only needed to protect interrupts from dereferencing
the sigio pointer in an object when the sigio itself is being destr

Redo the sigio locking.

Turn the sigio sx into a mutex.

Sigio lock is really only needed to protect interrupts from dereferencing
the sigio pointer in an object when the sigio itself is being destroyed.

In order to do this in the most unintrusive manner change pgsigio's
sigio * argument into a **, that way we can lock internally to the
function.

show more ...


# 596325f1 16-Apr-2002 John Baldwin <jhb@FreeBSD.org>

- Lock proctree_lock instead of pgrpsess_lock.
- Use temporary variables to hold a pointer to a pgrp while we dink with it
while not holding either the associated proc lock or proctree_lock. It

- Lock proctree_lock instead of pgrpsess_lock.
- Use temporary variables to hold a pointer to a pgrp while we dink with it
while not holding either the associated proc lock or proctree_lock. It
is in theory possible that p->p_pgrp could change out from under us.

show more ...


# 12c79eb2 03-Apr-2002 Ruslan Ermilov <ru@FreeBSD.org>

Dike out a highly insecure UCONSOLE option.
TIOCCONS must be able to VOP_ACCESS() /dev/console to succeed.

Obtained from: OpenBSD


# 2a60b9b9 02-Apr-2002 Seigo Tanimura <tanimura@FreeBSD.org>

Fix leakage of p_pgrp lock.


# 44731cab 01-Apr-2002 John Baldwin <jhb@FreeBSD.org>

Change the suser() API to take advantage of td_ucred as well as do a
general cleanup of the API. The entire API now consists of two functions
similar to the pre-KSE API. The suser() function takes

Change the suser() API to take advantage of td_ucred as well as do a
general cleanup of the API. The entire API now consists of two functions
similar to the pre-KSE API. The suser() function takes a thread pointer
as its only argument. The td_ucred member of this thread must be valid
so the only valid thread pointers are curthread and a few kernel threads
such as thread0. The suser_cred() function takes a pointer to a struct
ucred as its first argument and an integer flag as its second argument.
The flag is currently only used for the PRISON_ROOT flag.

Discussed on: smp@

show more ...


# 4d77a549 19-Mar-2002 Alfred Perlstein <alfred@FreeBSD.org>

Remove __P.


# 85f190e4 14-Mar-2002 Alfred Perlstein <alfred@FreeBSD.org>

Fixes to make select/poll mpsafe.

Problem:
selwakeup required calling pfind which would cause lock order
reversals with the allproc_lock and the per-process filedesc lock.
Solution:
Instead of

Fixes to make select/poll mpsafe.

Problem:
selwakeup required calling pfind which would cause lock order
reversals with the allproc_lock and the per-process filedesc lock.
Solution:
Instead of recording the pid of the select()'ing process into the
selinfo structure, actually record a pointer to the thread. To
avoid dereferencing a bad address all the selinfo structures that
are in use by a thread are kept in a list hung off the thread
(protected by sellock). When a selwakeup occurs the selinfo is
removed from that threads list, it is also removed on the way out
of select or poll where the thread will traverse its list removing
all the selinfos from its own list.

Problem:
Previously the PROC_LOCK was used to provide the mutual exclusion
needed to ensure proper locking, this couldn't work because there
was a single condvar used for select and poll and condvars can
only be used with a single mutex.
Solution:
Introduce a global mutex 'sellock' which is used to provide mutual
exclusion when recording events to wait on as well as performing
notification when an event occurs.

Interesting note:
schedlock is required to manipulate the per-thread TDF_SELECT
flag, however if given its own field it would not need schedlock,
also because TDF_SELECT is only manipulated under sellock one
doesn't actually use schedlock for syncronization, only to protect
against corruption.

Proc locks are no longer used in select/poll.

Portions contributed by: davidc

show more ...


# 183ccde6 11-Mar-2002 Seigo Tanimura <tanimura@FreeBSD.org>

Stop abusing the pgrpsess_lock.


# 92c914f9 02-Mar-2002 Seigo Tanimura <tanimura@FreeBSD.org>

Fix lock leakage and late unlock.

Submitted by: bde


# e9be968e 24-Feb-2002 Poul-Henning Kamp <phk@FreeBSD.org>

Fix a typo (?) in previous commit told ttyprintf() to print the integer
part of the user-time as a 64bit quantity. This resulted in weird
output from SIGINFO.


# f591779b 23-Feb-2002 Seigo Tanimura <tanimura@FreeBSD.org>

Lock struct pgrp, session and sigio.

New locks are:

- pgrpsess_lock which locks the whole pgrps and sessions,
- pg_mtx which protects the pgrp members, and
- s_mtx which protects the session member

Lock struct pgrp, session and sigio.

New locks are:

- pgrpsess_lock which locks the whole pgrps and sessions,
- pg_mtx which protects the pgrp members, and
- s_mtx which protects the session members.

Please refer to sys/proc.h for the coverage of these locks.

Changes on the pgrp/session interface:

- pgfind() needs the pgrpsess_lock held.

- The caller of enterpgrp() is responsible to allocate a new pgrp and
session.

- Call enterthispgrp() in order to enter an existing pgrp.

- pgsignal() requires a pgrp lock held.

Reviewed by: jhb, alfred
Tested on: cvsup.jp.FreeBSD.org
(which is a quad-CPU machine running -current)

show more ...


1...<<11121314151617181920>>...35