Does this concept only apply to terminal drivers (which is what most sites cover) or to any driver in general?
Drivers – Difference Between Raw and Cooked Device Drivers
devicesdriversterminal
Related Solutions
Originally, "tty" had two definitions: the hardware (now the emulator) and the driver (interfaced through /dev/pty* or /dev/tty*).
The hardware/emulator was/is responsible for:
- Taking a stream of data and presenting it; this included interpreting control sequences like "move cursor left", "blinking cursor", "clear-screen" although these control sequences were often different among manufacturers.
- Sending keycodes for keys typed by the user; most of these were standard ASCII characters, but some terminals sent propriety keycodes for even standard keys.
The 'tty' driver was responsible for:
- Managing the buffering, in raw or canonical mode; for example, buffering a line of characters until Enter is pressed.
- Managing the control flow; e.g. being able to stop/continue with Cntl-s/Cntl-q.
- Translating propriety keycodes to standard ASCII, where applicable.
- Intercepting certain control characters (like Cntl-c and Backspace) and processing them appropriately (send SIGINT on a Cntl-c or signal an EOF on Cntl-d.
- Canonical display of characters, for example, if
echo
is turned off, then do not send feedback (character typed) back to the terminal.
The terminfo and termcap databases managed what terminal control characters should be sent for an operation (like 'clear-screen'). These control sequences were/are not interpreted by the driver, but by the hardware/emulator.
Was the idea behind the controller to be able to control devices from a different manufacturers with the same driver?
No. The primary purpose is to provide part of the interface between devices and the processor. A controller has its own driver; this is in addition to any drivers necessary for the devices connected to it.
The reason the interface is necessary is that the processor is highly specialized; controllers are sort of translators from the specialized world of the processor to the multiverse of devices. The processor only has one physical data connection to the outside (the bus), not a variety of them, and in fact, generally intermediary between controllers and the processor are bridges which connect the processor to the motherboard. Device controllers are then connected to the motherboard and communicate via a bridge. So there are four discrete physical entities in the chain: processor -> bridge -> controller -> device, all of which involve their own software drivers (a driver for the processor, for the bridge chipset, then for each of the controllers, and for each of the devices).
If you look at the diagram below from this wikipedia article, the blue boxes at the bottom represent device controllers.
[By Alexander Taubenkorb, Creative Commons Attribution-Share Alike 3.0]
Best Answer
The terms raw and cooked only apply to terminal drivers. "Cooked" is called canonical and "raw" is called non-canonical mode.
The terminal driver is, by default a line-based system: characters are buffered internally until a carriage return (Enter or Return) before it is passed to the program - this is called "cooked". This allows certain characters to be processed (see
stty(1)
), such as CtrlD, CtrlS, CtrlU, Backspace); essentially rudimentary line-editing. The terminal driver "cooks" the characters before serving them up.The terminal can be placed into "raw" mode where the characters are not processed by the terminal driver, but are sent straight through (it can be set that INTR and QUIT characters are still processed). This allows programs like
emacs
andvi
to use the entire screen more easily.You can read more about this in the "Canonical mode" section of the
termios(3)
manpage.