Colin Walters <[email protected]> writes: > The problem with that is - what's the default? If it's on, then I'd > have to carry a patch forever to flip it off by default. If it's off, > then people who run X.org on operating systems without this > functionality would have to carry a patch to flip it on. Or maybe they > wouldn't care, not sure.
That's my concern with a built-time option -- you'll have to carry a patch to build the server in a special way, where as an option, you can upstream patches to display managers to enable the option in the X server as they'll presumably always want to manage the server themselves. >> Mostly because some video drivers behave very badly >> if you don't clean up on server crash. > > Hm, can you be more specific? Is this something relevant even for KMS > or just the old UMS? I think it's relevant for any environment -- if the server does nothing at shutdown, then you're generally left on a console in graphics mode which makes it pretty hard to use the machine unless some daemon takes over and recovers the system for you. That's why I think having this as an option, either in the config file or the command line, might be more useful for most people. While most people use a display manager, there are still a number of situations where 'startx' makes sense. > Regardless though I think I'd rather have that problem than the > possibilities of deadlock, unexpected recursion, etc. that one has when > trying to "handle" SIGSEGV. The amount of code the X server runs inside > a signal context on SEGV is huge, if you start reading from > OsSigHandler() -> FatalError() -> AbortServer() -> CloseDownDevices(). No argument there; having the server do less when it crashes would definitely be a good idea. For KMS devices, all that is really necessary is to get the console back to cooked mode and exit, I think. > Although the most important thing to me at the moment is that the OS > detect the fact that X has crashed, without me having to run regexps on > log files. It looks like I could kind of do that now without patching X > by passing -core as an argument, which will trigger a raise(SIGABRT). > If you're not keen on taking this patch, then I can probably do that. We've got lots of time to consider the situation; any non-bugfix patches should wait for the 1.15 release cycle in any case. -keith
pgp62i2icRhf1.pgp
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
