Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!newsserver.jvnc.net!gmd.de!mururoa!veit
From: veit@mururoa.gmd.de (Holger Veit)
Subject: More on console device (was: Re: Patch for hanging console)
Message-ID: <1993Apr20.152433.15601@gmd.de>
Sender: veit@mururoa (Holger Veit)
Nntp-Posting-Host: mururoa
Organization: GMD, Sankt Augustin, Germany
References: <1993Apr20.115301.2477@gmd.de> <1r10ssINNqc2@fstgds01.tu-graz.ac.at>
Date: Tue, 20 Apr 1993 15:24:33 GMT
Lines: 84
In article <1r10ssINNqc2@fstgds01.tu-graz.ac.at>, chmr@edvz.tu-graz.ac.at (Christoph Robitschko) writes:
|> In article <1993Apr20.115301.2477@gmd.de> Holger Veit (veit@mururoa.gmd.de) wrote:
[...discussion about vnode usage for resolving of /dev/console multiplexer problem...]
|> While I agree that device drivers *shouldn't* know about the vnode layer,
|> I know of no other way to solve this problem. Reference counts on devices
|> are kept at the vnode layer, and the console driver *has to* use these
|> reference counts to call the underlaying driver sensibly.
[...]
|> While I also think the pccons driver has to be changed to follow the rules
|> for device drivers (changing the address of the video RAM in locore.s is
|> a rude hack, IMHO), this has nothing to with my patch.
|> You could patch the pccons driver (whichever variant you like), and you
|> would still have the same problems when the console is mapped to another
|> device (e.g. serial console).
|>
|> MY PATCH IS IN NO WAY LIMITED TO VGA CONSOLE, but a general solution to
|> this problem, for all devices that could possibly used as a console !
The problem is that the vnode concept doesn't support the idea of
runtime multiplexing of different drivers reachable by a single vnode, and
furthermore accessing the same driver by a different vnode. The problem
wouldn't occur if the additional link /dev/vga to the same device driver
wouldn't be used. So the real solution is indeed to decouple logical
devices like /dev/console from physical ones (call it /dev/pccons or /dev/vga,
i.e. major 12, minor 0), not to circumvent the existing problem by correcting
it with the help of the vnode layer.
|> The problem that the screen remains in graphics mode when the X server
|> crashes is a different one. To solve this, you have to do the switching
|> to/from graphics mode within the driver. After all, device drivers were
This is what I intend to do for a long time ("graphics console"), but see
below for the problem (which you already mentioned).
|> created to keep the applications away from the hardware-specific things.
|> So, ideally the X server would do an ioctl(switch to graphics), and
|> the driver speaks to the video hardware. (About the way the free
|> Apollo X-server is implemented: The server makes gpr [graphics primitives]
|> calls, and the card-specific driver does the rest).
This is indeed the difficulty that makes kernel debugging impossible when
the xserver has crashed. Syscons for instance is such a "nice weather program";
it uses the built-in SYSV features of the xserver to allow virtual terminal
switching, but it requires that the xserver massively supports playing the game.
If the xserver does not respond to the switch event or the kernel crashes
during xserver running, there is no way other then pushing the large button,
even with a ddb compiled into the kernel.
|> In the real world, on the PC market there are so many different
|> video cards that this would overfill the kernel, and also be
|> error-prone.
|> Having the hardware-specific information in both the kernel and the
|> application, is worse.
Agreed.
|> The best alternative *for now* is to have the knowledge about the
|> SVGA cards in the X server (it is already there, after all), and
|> the kernel to depend on the application in this respect.
|> This may change if/when we have loadable kernel modules.
This is the situation as is, and it is exactly the problem I am currently
having. It is no problem (hehe:-)) to write a service routine that
switches a particular video card into some video mode, but all of them in
a single kernel would exceed any memory limit (at least the 640k limit:-)).
The probing code itself to detect a card is not that large, and something
like this is already in "codrv". What is needed are loadable kernel
modules of a specific type: not modules that can be loaded by an
external utility (modload, like on a Sun), but those that are
linked in by the kernel on its own demand. This will lead to a
scattered kernel consisting of several parts, which I found is not
what the BSD purists like (the alternative is a /386bsd.a).
|>
|> Christoph
Holger
--
Dr. Holger Veit | INTERNET: Holger.Veit@gmd.de
| | / GMD-SET German National Research | Phone: (+49) 2241 14 2448
|__| / Center for Computer Science | Fax: (+49) 2241 14 2342
| | / P.O. Box 13 16 | Three lines Signature space
| |/ Schloss Birlinghoven | available for rent. Nearly
DW-5205 St. Augustin, Germany | unused, good conditions