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: More on console device (was: Re: Patch for hanging console) Date: 20 Apr 1993 18:59:34 +0200 Organization: Technical University of Graz, Austria Lines: 72 Message-ID: <1r1a5mINNqiu@fstgds01.tu-graz.ac.at> References: <1993Apr20.152433.15601@gmd.de> NNTP-Posting-Host: fstgds01.tu-graz.ac.at X-Newsreader: TIN [version 1.1 PL7] In article <1993Apr20.152433.15601@gmd.de> Holger Veit (veit@mururoa.gmd.de) wrote: > 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...] > |> 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. To say it again: The "console" does not have to be a graphics card, it can be any character device (serial console is only an example). And I see no reason why you should not have a getty running on both /dev/vga and /dev/com2, and use one or the other for console, too. And how would you prevent your users to use the physical devices (/dev/vga in this example) when a logical device (/dev/console) also points to the same device ? [ The rest is in fact another thread, about pccons drivers] > 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. Yes. > 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". If I remember correctly, the card detection in the old keycap was only to print the card type on coattach. This is a waste IMHO. Can't speak for the newer versions of codrv, though. > 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). I'm not sure what you mean. Why would a modload not suffice ? I'm thinking of something like this: Have a skeleton driver (statically) in the kernel, and in /etc/rc do the following: modload et4000.driv (No card found, not loaded) modload trident.driv (card found, attach) ... What exactly do you mean with "linked in by the kernel on its own demand" ? Christoph Maybe we should move this discussion in comp.os.386bsd.development ?