FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=release%2F8.1.0 2009-10-10T18:24:54Z 2009-10-10T18:24:54Z Marcel Moolenaar marcel@FreeBSD.org 2009-10-10T18:24:54Z urn:sha1:879632020a655570c2e441380ea9d800f95e7620 Fix RTS/CTS flow control, broken by the TTY overhaul. The new TTY interface is fairly simple WRT dealing with flow control, but needed 2 new RX buffer functions with "get-char-from-buf" separated from "advance-buf-pointer" so that the pointer could be advanced only when ttydisc_rint() succeeded. Approved by: re (kib) 2008-08-20T08:31:58Z Ed Schouten ed@FreeBSD.org 2008-08-20T08:31:58Z urn:sha1:bc093719ca478fe10b938cef32c30b528042cbcd The last half year I've been working on a replacement TTY layer for the FreeBSD kernel. The new TTY layer was designed to improve the following: - Improved driver model: The old TTY layer has a driver model that is not abstract enough to make it friendly to use. A good example is the output path, where the device drivers directly access the output buffers. This means that an in-kernel PPP implementation must always convert network buffers into TTY buffers. If a PPP implementation would be built on top of the new TTY layer (still needs a hooks layer, though), it would allow the PPP implementation to directly hand the data to the TTY driver. - Improved hotplugging: With the old TTY layer, it isn't entirely safe to destroy TTY's from the system. This implementation has a two-step destructing design, where the driver first abandons the TTY. After all threads have left the TTY, the TTY layer calls a routine in the driver, which can be used to free resources (unit numbers, etc). The pts(4) driver also implements this feature, which means posix_openpt() will now return PTY's that are created on the fly. - Improved performance: One of the major improvements is the per-TTY mutex, which is expected to improve scalability when compared to the old Giant locking. Another change is the unbuffered copying to userspace, which is both used on TTY device nodes and PTY masters. Upgrading should be quite straightforward. Unlike previous versions, existing kernel configuration files do not need to be changed, except when they reference device drivers that are listed in UPDATING. Obtained from: //depot/projects/mpsafetty/... Approved by: philip (ex-mentor) Discussed: on the lists, at BSDCan, at the DevSummit Sponsored by: Snow B.V., the Netherlands dcons(4) fixed by: kan 2008-05-04T23:29:38Z Peter Wemm peter@FreeBSD.org 2008-05-04T23:29:38Z urn:sha1:43d7128c1450d36af259094b7cf39c0c4d17908c ALT_BREAK_TO_DEBUGGER. In addition to "Enter ~ ctrl-B" (to enter the debugger), there is now "Enter ~ ctrl-P" (force panic) and "Enter ~ ctrl-R" (request clean reboot, ala ctrl-alt-del on syscons). We've used variations of this at work. The force panic sequence is best used with KDB_UNATTENDED for when you just want it to dump and get on with it. The reboot request is a safer way of getting into single user than a power cycle. eg: you've hosed the ability to log in (pam, rtld, etc). It gives init the reboot signal, which causes an orderly reboot. I've taken my best guess at what the !x86 and non-sio code changes should be. This also makes sio release its spinlock before calling KDB/DDB. 2007-12-25T17:52:02Z Robert Watson rwatson@FreeBSD.org 2007-12-25T17:52:02Z urn:sha1:3de213cc00f2889d2cd693968fd38c10a7f5def1 for that argument. This will allow DDB to detect the broad category of reason why the debugger has been entered, which it can use for the purposes of deciding which DDB script to run. Assign approximate why values to all current consumers of the kdb_enter() interface. 2007-04-02T22:00:22Z Marcel Moolenaar marcel@FreeBSD.org 2007-04-02T22:00:22Z urn:sha1:f8100ce2a70db5c60672578fee913d986ac1cf01 it obtained through the uart_class structure. This allows us to declare the uart_class structure as weak and as such allows us to reference it even when it's not compiled-in. It also allows is to get the uart_ops structure by name, which makes it possible to implement the dt tag handling in uart_getenv(). The side-effect of all this is that we're using the uart_class structure more consistently which means that we now also have access to the size of the bus space block needed by the hardware when we map the bus space, eliminating any hardcoding. 2007-03-28T18:26:12Z Marcel Moolenaar marcel@FreeBSD.org 2007-03-28T18:26:12Z urn:sha1:1c5e367bcca17bd3688e87bb82424bee540bd379 system devices (i.e. console, debug port or keyboard), don't stop after the first match. Find them all and keep track of the last. The reason for this change is that the low-level console is always added to the list of system devices first, with other devices added later. Since new devices are added to the list at the head, we have the console always at the end. When a debug port is using the same UART as the console, we would previously mark the "newbus" UART as a debug port instead of as a console. This would later result in a panic because no "newbus" device was associated with the console. By matching all possible system devices we would mark the "newbus" UART as a console and not as a debug port. While it is arguably better to be able to mark a "newbus" UART as both console and debug port, this fix is lightweight and allows a single UART to be used as the console as well as a debug port with only the aesthetic bug of not telling the user about it also being a debug port. Now that we match all possible system devices, update the rclk of the system devices with the rclk that was obtained through the bus attachment. It is generally true that clock information is more reliable when obtained from the parent bus than by means of some hardcoded or assumed value used early in the boot. This by virtue of having more context information. MFC after: 1 month 2007-02-23T12:19:07Z Paolo Pisati piso@FreeBSD.org 2007-02-23T12:19:07Z urn:sha1:ef544f631226436ef590825881e7a28369df82f6 bus_setup_intr() o add an int return code to all fast handlers o retire INTR_FAST/IH_FAST For more info: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=465712+0+current/freebsd-current Reviewed by: many Approved by: re@ 2006-04-28T18:29:23Z Marcel Moolenaar marcel@FreeBSD.org 2006-04-28T18:29:23Z urn:sha1:a31f91a061ec20129d1ccb2377c0e28c25210146 2006-03-30T18:37:03Z Marcel Moolenaar marcel@FreeBSD.org 2006-03-30T18:37:03Z urn:sha1:8af03381d8a55b75320465312ee779c11c7dcaf5 2006-02-24T05:40:17Z Marcel Moolenaar marcel@FreeBSD.org 2006-02-24T05:40:17Z urn:sha1:ea54941449f91ed73a68a06ddb41716fdf5a4a5a