LCA: Andrew Tanenbaum on creating reliable systems [LWN.net]

LCA: Andrew Tanenbaum on creating reliable systems

Posted Jan 19, 2007 4:40 UTC (Fri) by drag (subscriber, #31333) [Link]

Well I asked this on the Xorg mailing list and the basic respons was when the drivers in Linux bork, X restarts. Also you can do the ctl-alt-backspace to break out of X when it locks up. This is basicly what Vista has implimented, but in a more automatic manner.

If the driver fails in a manner that borks the hardware then your screwed irregardless in both operating systems.

That's my limited understanding. The details on the internet on what actually happens with the video card reset features in Vista is few and far between. So don't take it as the gospil truth.

The video drivers in Linux have always been userspace, which is suppose to be a big new feature for Vista. The 'DRM' Linux kernel modules allow the 'DRI' drivers (drivername_dri.so) to control the hardware. As have been the USB drivers, optionally.

Another example seems like Microsoft is full of shit about a lot of other aspects of Vista that are touted as huge improvements.

For example they toute their 'resolution independant ui'. this is to make your UI to work better with very high resolution displays. In reality all this means is that you can change the DPI for the display (with a reboot, I beleive).

Effectively they just implimented a feature that was aviable in other OSes for years and years and it's this big new selling point for them.

We need clients that can survive an X restart.

Posted Jan 19, 2007 18:43 UTC (Fri) by AJWM (guest, #15888) [Link]

> when the drivers in Linux bork, X restarts.

The problem is, that pretty much takes all the X clients with it, so you've lost your whole session anyway.

Now, arguably that's the fault of the client(s) rather than the X server, but I've yet to see an X client program written that could gracefully recover (ie to the point of picking up exactly where it left off) if its X display was yanked out from under it and restarted. It's been long enough since I programmed at the Xlib level that I don't recall how much state (of windows, etc) is in the server vs the client (via the X libraries), but I imagine that enough state _could_ be kept in the client (again, courtesy of the xlib) to redisplay to the new X server everything that was there when the old one borked.

It'd be an interesting and non-trivial programming exercise, but a massively useful one. (Nothing worse than having numerous windows open, having your X display lock up, and knowing that the only thing you can do is blow it all away even though the client programs are still perfectly OK - or will be until their display connection is killed.)

We need clients that can survive an X restart.

Posted Jan 19, 2007 21:27 UTC (Fri) by jwb (guest, #15467) [Link]

Actually X11 is (used to be) stateless. These days with backing stores and compositing it's not quite true. GTK+ has had for years the ability to disconnect from one display and reconnect to another, which also means that you can connect it to a dummy display while your real display restarts. However this toolkit capability has been long neglected by application writers.

We need clients that can survive an X restart.

Posted Jan 20, 2007 0:31 UTC (Sat) by drag (subscriber, #31333) [Link]

Well I would think that compositing would make it easier to make things stateless, since windows and such are not rendered on the actual display but in off-screen buffers.

I'd think you'd just have to keep those off-screen buffers alive and when the main display comes back up then you "re-composite" them.

Maybe you need a different thread for the application management vs the part of the X server that does the actual rendering or something, I don't know.

We need clients that can survive an X restart.

Posted Jan 20, 2007 8:21 UTC (Sat) by cworth (subscriber, #27653) [Link]

> GTK+ has had for years the ability to disconnect from one display and
> reconnect to another, which also means that you can connect it to a dummy
> display while your real display restarts.

There is a missing piece here though. The GTK+ code can successfully
migrate an X connection through a client-initiated disconnect. But it
turns out that design flaws in Xlib make it impossible for a client
to cleanly recover from an X server that disappears out from under the
client.

I've actually looked into what it would take to retrofit Xlib to add
what's missing. It'd be possible, but it would require a programmer
with a stronger constitution than I have to wade through the Xlib
internals to make the fix. And then one would still need to fixup
GTK+ to properly respond to the new XServerDisconnected event that
would have to be added.

Meanwhile, a more realistic approach is to get toolkits to switch to
XCB which doesn't suffer from the same shortcoming as Xlib in this area.

> However this toolkit capability has been long neglected by application
> writers.

I agree that there are some interesting aspects of migrating applications
from one X server to another that applications aren't taking advantage of.

But for the idea of replacing an X server for an entire session---I'd much
rather that be something that not require any application knowledge at all.
That's a much quicker route to making it work reliably for as many
applications as possible.

-Carl

We need clients that can survive an X restart.

Posted Jan 22, 2007 5:19 UTC (Mon) by elanthis (guest, #6227) [Link]

With XCB around, is it really necessary to retrofit Xlib with those changes? Either way, client apps will need to be updated, and XCB brings a lot of other benefits with it, no? Most apps use a toolkit, so once you get the major ones ported (including whatever today's popular Motif clone is, and Tk) you should be set.