Date: Wed, 22 Jan 2003 13:51:16 -0800 From: Marcel Moolenaar <marcel@xcllnt.net> To: Doug Rabson <dfr@nlsystems.com> Cc: "Pedro F. Giffuni" <giffunip@yahoo.com>, arch@FreeBSD.ORG Subject: Re: the mythical syscons redesign document ( was Re: Porting wscons ) Message-ID: <20030122215115.GC590@dhcp01.pn.xcllnt.net> In-Reply-To: <1043236066.28124.6.camel@builder02.qubesoft.com> References: <20030122010246.52789.qmail@web13404.mail.yahoo.com> <1043236066.28124.6.camel@builder02.qubesoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jan 22, 2003 at 11:47:46AM +0000, Doug Rabson wrote: > > The main sticking point for this stuff is that console is needed before > the device tree is probed. I think the right approach will be to define > a set of interfaces for the video console and then implement those > interfaces using the lower-level kobj system. This allows you to put > together a working console output system before the rest of the system > is up and running. This is what's been building in my head so far. It's graph-like and probably too early for public exposure, but what the hee. Related frameworks probably include netgraph and geom: 4 interfaces: top Your regular file I/O. It's the highest level interface known by the console framework. bottom A pseudo interface that denotes the lack of interface. Probably just a formality, but may have its use when implemented... con_out A procedural interface typically used by output devices. con_in A procedural interface typically used by input devices. A typical serial console is implemented by a sio node that has top and bottom interfaces. The top interface is directly "attached" to the UART. Consequently, you cannot attach a terminal emulator to it. A non-typical sio node may do so. Whether you want to have sio included like this is irrelevent. A VGA display driver is implemented by a vga node that implements the bottom and con_out interfaces. The con_out interface is directly tied to the VGA hardware. Non-VGA display drivers do the same. A keyboard driver implements bottom and con_in. An input terminal emulator (TE) implements con_in and top and an output TE implements con_out and top. A null-TE hooks up top with con_in or con_out without doing any emulation. Note that I split TEs in output and input here, but that's mostly from an interfacing point of view. You cannot split TEs, because state is shared between input and output. Hence, you can attach a vga node to a output TE and a keyboard to an input TE and have the basics of a console with terminal emulation. Other building blocks are multiplexers with which you can implement virtual consoles and demultiplexers with which you can allow multiple keyboards for the same terminal or multiple identical displays (not really the same as multi-head). These typically implement multiple con_in or multiple con_out interfaces. This asks for a top and bottom side of a node or an input/output side (consumer/producer). We'll see... Note that text-only VGA drivers themselves have the ability to multiplex by switching the display page. So, one could implement virtual consoles with the VGA driver only. Need to keep this in mind... One could envision top-top nodes, such as encoding translators or file multiplexers/demultiplexers, but they don't really add any value that's not already here (flexibility). The prime responsibility of the console driver is to hook up these interfaces in a meaningful fashion. Lot's can be hooked up dynamicly, but you need some directives. Probably compile-time defaults. I see it working roughly like: o Low-level console hooks up to the con_out and con_in interfaces of predetermined drivers. Maybe use a different interface for this (which is basicly a subset of con_in and con_out). o Console framework initialization, which involves getting all the TEs (either compiled-in or loaded as a module). o Bus enumeration causes low-level nodes to be added such as display and keyboard. Modules add to the dynamic nature or this process. o Everything gets hooked up. This is currently a magical process as it's not fleshed out. o sysctl or ioctl or whatever can be used to change the "graph" by swapping TEs or adding/removing an additional keyboard. Again, mostly magic... Anyway, you get the picture: building blocks. Objects if you like the OO paradigm. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030122215115.GC590>