[PATCH] os/osinit: Allow builders to --disable-segv-handler

[Peter Hutterer]

On Mon, Jan 21, 2013 at 11:00:01AM -0500, Colin Walters wrote:
> On Mon, 2013-01-21 at 00:51 -0800, Keith Packard wrote:
> 
> > Seems like this might benefit from being a run-time option, rather than
> > a build-time option?
> 
> 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.

Give it a run-time option and make the default build-time? That way everyone
gets the best out of both worlds.

> >  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?
> 
> 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().

Most of the input path in the AbortServer handler is not needed, we can just
bail out directly. The only thing we need is a new API to tell input devices
that they're about to be crashed, allowing them to reset the device. This
isn't needed for evdev, but some legacy serial devices would benefit from
this. It's just never been high enough on the priority list for me.

Cheers,
   Peter

> 
> 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.