Date: Mon, 3 Apr 95 16:22:26 MDT From: terry@cs.weber.edu (Terry Lambert) To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-hackers@FreeBSD.org Subject: Re: grafx console & DDB Message-ID: <9504032222.AA09247@cs.weber.edu> In-Reply-To: <199504032012.WAA00745@uriah.heep.sax.de> from "J Wunsch" at Apr 3, 95 10:12:36 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > No, the generic soloution is to not allow the X server direct access > > to the mode registers, and instead force it to go through a kernel > > driver. > > Of course, but it's even harder to make than the vm86() story. In > case of a panic(), almost everything it's lost, so i don't really care > if the X server shuts down nicely. Sorry, but that's not an argument; the point is not to shut down the X server at all, but to hide the video mode switching in code that is available to the kernel at all times, even after panic. The argument that the code might be lost in that case is the same as the argument that the kernel debugger might be lost -- if kernel text gets overwritten, there's a bigger problem than a post-facto use of a debugger could find anyway. I think I could argue against the VM86() story from another angle as well; a VM86() call to video BIOS is no more likely to be able to restore from a wierd video mode than a BIOS call would be able to reset 16550 serial ports out of FIFO mode. In other words, the BIOS might not know how to reset the modes, or if it does, it might not know how to reset everything that needs to be reset if the mode wasn't established using the BIOS in the first place. It's a can of works that ends up substituting a BIOS that doesn't know about the hardware settings effected by the server for a console driver that didn't know about the hardware settings effected by the server -- not a win. [ ... INT 10 video BIOS disabling of interrupts ... ] > I didn't think of that. Perhaps vm86() should always run non- > privileged (except of the IOPL), and the GP fault being ignored? I don't think you could do that and keep compatability. 8-(. The BIOS out to be there via VM86() just so there is always a way to do something, but it ought to be the second choice. Taking a couple of interrupt hits on a single user system (ie: nobody dialed in on the serial port or whatever) to get a working X on the console is one thing, but depending on no one being there in all cases would probably be a mistake. 8-(. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9504032222.AA09247>