nisse@lysator.liu.se (Niels Möller) writes: > To get this right, one have to use some kind of frame buffer device > instead of having the X server bang directly on the hardware. All > Unices I've heard of have got this for ages, except Linux on PC > hardware (not sure about the *bsd:s on PC hardware, though). It's more a misfeature of PC hardware. On most other architectures you have no choice, Only the PC still uses text mode as a performance hack. It would indeed be interesting how other PC Unices do it, especially things like Solaris that sprang from fb-only platforms. > I believe things are getting better, but I haven't followed the > linux framebuffer stuff and kgi closely enough to know. Well, I'm using vesafb right now, which supports a wide range of graphic cards. OTOH, it doesn't protect me from X crashes, because I still use the normal X server, bypassing the framebuffer device. The fbdev server can't do mode-switches with vesafb, and I think it is still unaccelerated. So the problem under Linux is that you can still access the bare hardware, with the expected consequences on crashes. > You have the choice of putting the hardware-banging code into the > kernel (like in those Linuxes that have /dev/fb), or putting it in > some user-level process/translator. If you choose the second > alternative, you still won't have much help from the kernel if the > user-space program crashes, you have just moved the problem from the X > server to some other user-level program. The theory goes, that a smaller program should crash less often. While the XFree86 people do a tremendous job in keeping the X server from crashing, those things happen (more often in the case of version 4). The rough picture I have looks like this: A translator exist that regulates access to the video hardware. It will take responsibility over the hw on bootup, when it is in a defined state. Whenever a program (X server, but also /hurd/term) wants to own the screen, it must request that from the video translator, which hands out means to talk to the hw (mapped video memory, io ports, ...) and keeps a channel open to the client program. Some sensitive operations (e.g. changing video mode) must not be done directly, but through the video translator[1]. When the program closes the communication channel (because of a normal or abnormal termination), the translator considers the client done, and puts the previous owner into power again, resetting video mode et al to old values. It should also be possible to build a protocol for changing ownership between multiple active clients for the implementation of virtual consoles. This may even be a pre-emptive model (it is cooperative under Linux AFAIK). Footnotes: [1] Ideally, these operations are prohibited by the hardware (e.g. access to some card registers is not allowed), when possible. Otherwise, misbehaving programs may still wreak havoc. The chance of a crashing program overwriting an unrecoverable value is nevertheless smaller than failing to do proper de-initialization. -- Robbe
Attachment:
signature.ng
Description: PGP signature