Feature:fbcon and Linux 2.2

Joseph Pranevich has written in to talk a bit about one of those features that might be slipping into Linux 2.2, the Frame Buffer Console. It's a nice summary of what it is, and why we might (or might not) want this feature.

The following was written by Slashdot reader Joseph Pranevich

Linux 2.2 and the Frame-Buffer Console

Please send all comments, complaints, etc on this document to its author, Joseph Pranevich, at [e-mail]. Feedback is appreciated and always welcome.

This document was written expressly for Slashdot but may be distributed freely. Republication in electronic or non-electronic forms or in another public forum is permitted only by permission of the author.

Since my initial release of my 'Wonderful World of Linux 2.2' document (a simple list of feature additions for Linux 2.2 for the non-techy user), I have received many, many questions regarding this and that. However, the questions I have been asked most frequently all revolve around Linux 2.2's newest (and most shocking) kernel addition: the frame-buffer console driver. 'What's the big deal?' you say? This document will attempt to explain exactly why this is such a 'big deal' and introduce the non-technical Linux user to the basics of the Linux video subsystem and give a number of pros and cons to the (more than just proposed) new system. Enjoy!

Before one can understand the implications of the new, kernel based, fbcon system, one must have a working understanding of how the video drivers in Linux operate. If you are already familiar with the video driver subsystem of Windows then this may come as a bit of a shock to you...

1) A Peek at What We Have Today

The current video subsystem is divided into, at best, three distinct parts: the text-mode driver, the console video driver, and the X server. Now, only the text-mode portion (in the kernel) is carved in stone, the other two bits are optional but represent a common configuration for most distributions. For the purposes of this introduction, let us assume that your console driver is the SVGAlib.

In any scenario, the only portion of the video subsystem that is truly carved in stone is the text-mode driver. (Even if you are using a serial console, the console driver manipulates the serial port as if it were any other text device.) This is a driver, in the kernel, that controls cursor positioning and video hardware features and provides a set of vt100 interfaces for the manipulation of the text data. Additionally, the kernel driver knows how to work with any special other features of your card, including and especially using video memory for scrollback, etc. But, through all this support, this kernel driver contains NO graphic primitives of any kind.

The console graphic driver (actually, a library) is the next component of the Linux video subsystem. This library starts where the kernel leaves off, by providing direct access to the graphical capabilities of many video cards. The reality of the situation here is that far too few video devices are supported in full by this library, causing it to fall into disuse.

The third and final component of this model is the X server, a driver (and more) that, like the console driver, provide a uniform interface to the graphical capabilities of your hardware. Unlike the console driver, however, the X server is also in charge of a number of network and graphic-device sharing functions that make it somewhat bloated for low-memory use and difficult to use with stand-alone applications. In addition, many X servers are not free.

It should be obvious, even from just looking at the above, that this system is rather complicated and prone to problems. (What happens when you have multiple driver layers all trying to talk at the same time?) Which is not to say that it is bad. On the contrary, this system has stood the test of time in the UNIX/Linux world and is well-supported by the community.

2) A Preview of What We'll Have Tomorrow

The new kernel system is quite a bit simpler than the above example. In the new system, the kernel controls all direct video manipulation via the 'frame-buffer' device. This device, located at /dev/fb?, presents a device-independent API to the user-layer for manipulating any video device that you have a driver for. Under this new system, you would still need to run an X server to provide the network-connectivity of the previous system, but everyone would run the same server (XF86_FBDev) and that would merely talk to the generic interface. (A new SVGAlib is expected to be developed that will behave likewise for legacy console applications.)

3) Issues

Unfortunately, this merely scratches the surface of the issue. By all accounts, neither system looks terribly bad. And what's more, the current system is well-tested and well-accepted by the community. So, why change?

The following is an assembled list of some of the defects of the systems, starting with the established trinity. I have attempted to give you the facts rather than opinions on these subjects and to allow you to best make up your own mind on the issue. I'm positive that I've left out some perfectly reasonable complaints either way, please feel free to email me with your own justifications so that I personally can make a better decision on the matter. (And, perhaps, include those reasons in a future version of this document.)

Personally, I'm just waiting and seeing whether this new system catches on or not...

3.1) Security

The first thing that comes to my mind when discussing the problems with not having graphic code in the kernel is the issue of security. (or, lack thereof.) Linux has been designed from the start as a very security-conscious system. On a Linux system, two things really constitute a breach of security (although the first can imply the second):

• Access to 'root' (administration) things by ordinary users Causing a freeze or other denial-of-service

To these ends, it was decided (quite rightly) that allowing direct access to hardware could result in big problems. Thus, Linux allows only certain privileged programs access to hardware manipulation.

To allow a program to write graphics to the screen using the console driver, the program must be owned and run by the site administrator, root. Since it would be inconvenient to have to log in as root every-time someone wanted to access one of these programs, a flag was invented ('setuid') to allow any user to run a specific root-owned program as if he or she were root. Thus, even regular users can run graphical programs.

Unfortunately, there is a big problem here. There is no way to distinguish between a program that only wants to manipulate video hardware and one that wants to be root in other ways. Being root implies complete control over the system and all of its files, programs, and network connections. One must only hope that these graphical programs don't have any errors or problems that would cause them to go awry and trash your system...

Fortunately, nearly all programs designed to run as root do so without any adverse side-effects. However, it is possible in some cases for a black hat (cracker) to gain complete access to a system by exploiting small holes in setuid root programs. Any and all binaries that access the hardware, including X servers, can be vulnerable to this attack if the programmers are not careful. And, once an attacker gets in...

The fbcon system resolves most of this security problem by exporting an interface that requires no special privileges to manipulate. It is even possible to run the X server for fbcon without root access. In fact, the only real drawback here is that if a driver *is* buggy and in the kernel, it could take down more of the machine than just a buggy user-space X server.

3.2) Driver Availability

The current system of drivers, at least as far as the X server is concerned, is well supported. Nearly all common cards are supported to some extent in XFree86 or by an alternate X server provider. In some cases, these servers are for-pay but that is the exception and not the rule. In terms of the console driver library however, less cards are supported fully. This lack of support for the console library makes it very difficult to reasonably support it as an option for graphical development.

fbcon solves one of these problems: no longer will there be a discrepancy between what cards are supported in X and what cards are supported at the console. On the downside however, fbcon currently properly supports only a small subset of the cards that either the X server or the console library supports. We shall have to wait and see whether or not we will have a truly usable driver-base for 2.2.

3.3) Portability

The current driver trinity is a well established fact in the UNIX world. svgalib has been ported to several other UNIXes for source compatibility. The concept of having an X server to control windowing applications is older than I am. However, the current driver system is severely lacking, at the console, with portability to non-SVGA systems. Not all platforms use SVGA compatible cards as their primary video source and those that don't will not be able to build the source for our console applications.

fbcon does not solve these problems either. The new system of video drivers would allow applications designed for Linux to run more easily on other Linux platforms. All Linux platforms, even those whose current console libraries are incompatible, will be able to share graphical programs. That's quite an accomplishment.

At the same time, compatibility with other UNIXes will be severely impaired. Linux is, so far as I know, the only UNIX to use this new variety of frame-buffer system. Those platforms that still rely on SVGAlib and other legacy methods of video control may have significant problems

3.4) Configuration

My biggest complaint with the present system of drivers is the lack of any kind of global configuration system. A lot of information, including monitor timings and etc., must be present in multiple locations to keep everything running smoothly. It could be argued that a decent system administrator should have no problem maintaining this system, but the fact of the matter is that any duplication of work opens the potential for subtle errors that may take time for a busy network administrator to locate and fix.

Once again, the new drivers take a stab at solving this problem but may come up short. Under the new system, this information would only need to be repeated only once: the module-load time. As the current implementation of the fbcon system is rather incomplete, it remains to be seen exactly how such a large number of parameters would be passed into the module. (Especially considering that it is likely that the module will be loading *before* access to the filesystems can be established and a config file can be read.)

4) Conclusion

In summary, I think that both of these systems have severe limitations. I admit to not being entirely the best source of information in this regard but I sincerely hope that I have made some of the issues leading to the new system easier to understand. I admit that I glossed over a number of details in my explanation, however I think that I have done a fairly good job at keeping the relative sides about even in terms of personal bias.

If you have any questions, comments, or suggestions...