[PATCH] os/osinit: Allow builders to --disable-segv-handler
keithp at keithp.com
Mon Jan 21 09:52:57 PST 2013
Colin Walters <walters at verbum.org> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 827 bytes
Desc: not available
More information about the xorg-devel