Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!paladin.american.edu!news.univie.ac.at!fstgds15.tu-graz.ac.at!fstgds01.tu-graz.ac.at!not-for-mail From: chmr@edvz.tu-graz.ac.at (Christoph Robitschko) Newsgroups: comp.os.386bsd.bugs Subject: Re: Patch for hanging console Date: 20 Apr 1993 16:21:16 +0200 Organization: Technical University of Graz, Austria Lines: 77 Message-ID: <1r10ssINNqc2@fstgds01.tu-graz.ac.at> References: <1993Apr20.115301.2477@gmd.de> NNTP-Posting-Host: fstgds01.tu-graz.ac.at X-Newsreader: TIN [version 1.1 PL7] In article <1993Apr20.115301.2477@gmd.de> Holger Veit (veit@mururoa.gmd.de) wrote: > In article <1993Apr19.224208.27016@cs.few.eur.nl>, pk@cs.few.eur.nl (Paul Kranenburg) writes: > |> In <1qttvcINNno2@fstgds01.tu-graz.ac.at> chmr@edvz.tu-graz.ac.at (Christoph Robitschko) writes: > |> >My fix creates a temporary vnode for the device where the console is > |> >mapped to, and keeps a reference on it as long as /dev/console is open. > > Device drivers shouldn't know about the upper representation layer. If this happens > to be changed some day (as it was with the "select patch"), several side > effects will have to be considered. Just for completeness: I don't believe > that the vnode representation will be changed soon. > A more simple solution might be a counter in the driver which counts the > several successful open and close calls to it, and does its cleanup when the > counter reaches zero. I don't know how you would implement this counter, given the fact that the close routines are only called on the *last* close of the device, while the open routine is called on *every* open of the device. 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. > > |> It seems a rather convoluted solution to this particular problem. This > |> whole "/dev/vga" business was a quick hack in the first place, but since > |> there are a whole bunch of XFree servers out there based on it, I'm afraid > |> w're stuck with it for the remaining lifetime of the .1 release. > |> > |> The terminal-, keyboard translation- and framebuffer-functions of the > |> current pccons driver must be decoupled, providing separate interfaces > |> for each (say, /dev/kbd, /dev/fb, etc). > > I agree completely here. > BTW:-) : This is exactly the way "codrv" was concepted although the > decoupling could be made more strong than it is in this code. But of course > there are a number of "improved pccons" variants out there that do not > follow this strategy. This code of course requires such vnode hacking :-(. > Another special feature of the "improved drivers" is that they pass > non-ascii information (scan codes) through the tty channel, which causes > interesting effects when the channel is in "scan code mode" and another process > grabs it, expecting ascii. Many of the "hanging-console-after-end-of-X11" > problems have to do with that indirectly (some were due to bugs in pts/ptclose, > others due to closing the /dev/console multiplexer device, however). 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 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 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). 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. 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. Christoph