Searched hist:228631 (Results 1 - 7 of 7) sorted by relevance

/freebsd-11-stable/sys/dev/uart/
H A Duart_tty.cdiff 228631 Sat Dec 17 13:17:31 MST 2011 avg kern cons: introduce infrastructure for console grabbing by kernel

At the moment grab and ungrab methods of all console drivers are no-ops.

Current intended meaning of the calls is that the kernel takes control of
console input. In the future the semantics may be extended to mean that
the calling thread takes full ownership of the console (e.g. console
output from other threads could be suspended).

Inspired by: bde
MFC after: 2 months
/freebsd-11-stable/sys/dev/dcons/
H A Ddcons_os.cdiff 228631 Sat Dec 17 13:17:31 MST 2011 avg kern cons: introduce infrastructure for console grabbing by kernel

At the moment grab and ungrab methods of all console drivers are no-ops.

Current intended meaning of the calls is that the kernel takes control of
console input. In the future the semantics may be extended to mean that
the calling thread takes full ownership of the console (e.g. console
output from other threads could be suspended).

Inspired by: bde
MFC after: 2 months
/freebsd-11-stable/sys/dev/usb/serial/
H A Dusb_serial.cdiff 228631 Sat Dec 17 13:17:31 MST 2011 avg kern cons: introduce infrastructure for console grabbing by kernel

At the moment grab and ungrab methods of all console drivers are no-ops.

Current intended meaning of the calls is that the kernel takes control of
console input. In the future the semantics may be extended to mean that
the calling thread takes full ownership of the console (e.g. console
output from other threads could be suspended).

Inspired by: bde
MFC after: 2 months
/freebsd-11-stable/sys/sys/
H A Dcons.hdiff 228631 Sat Dec 17 13:17:31 MST 2011 avg kern cons: introduce infrastructure for console grabbing by kernel

At the moment grab and ungrab methods of all console drivers are no-ops.

Current intended meaning of the calls is that the kernel takes control of
console input. In the future the semantics may be extended to mean that
the calling thread takes full ownership of the console (e.g. console
output from other threads could be suspended).

Inspired by: bde
MFC after: 2 months
/freebsd-11-stable/sys/kern/
H A Dkern_cons.cdiff 228631 Sat Dec 17 13:17:31 MST 2011 avg kern cons: introduce infrastructure for console grabbing by kernel

At the moment grab and ungrab methods of all console drivers are no-ops.

Current intended meaning of the calls is that the kernel takes control of
console input. In the future the semantics may be extended to mean that
the calling thread takes full ownership of the console (e.g. console
output from other threads could be suspended).

Inspired by: bde
MFC after: 2 months
/freebsd-11-stable/sys/dev/sio/
H A Dsio.cdiff 228631 Sat Dec 17 13:17:31 MST 2011 avg kern cons: introduce infrastructure for console grabbing by kernel

At the moment grab and ungrab methods of all console drivers are no-ops.

Current intended meaning of the calls is that the kernel takes control of
console input. In the future the semantics may be extended to mean that
the calling thread takes full ownership of the console (e.g. console
output from other threads could be suspended).

Inspired by: bde
MFC after: 2 months
/freebsd-11-stable/sys/dev/syscons/
H A Dsyscons.cdiff 228631 Sat Dec 17 13:17:31 MST 2011 avg kern cons: introduce infrastructure for console grabbing by kernel

At the moment grab and ungrab methods of all console drivers are no-ops.

Current intended meaning of the calls is that the kernel takes control of
console input. In the future the semantics may be extended to mean that
the calling thread takes full ownership of the console (e.g. console
output from other threads could be suspended).

Inspired by: bde
MFC after: 2 months

Completed in 178 milliseconds