On 12 July 2011 13:40, Dave Martin dave.martin@linaro.org wrote:
On Tue, Jul 12, 2011 at 01:10:24PM +0100, David Gilbert wrote:
Does it help address rth's concerns though?
Which ones in particular?
Good question - hence my prompt to rth at the bottom; I know he originally asked why not go to VDSO, so what I don't yet understand is whether he would accept the other alternatives.
Isn't this a bit over-the-top for the failure we're trying to catch?
Yes and no. Implementing such a solution just for this case would be very over-the-top. But integrating with a general mechanism for reporting errors if it exists (now or in the future) is very sensible.
Right - but I don't think we should be doing anything new here; we can't be the first people to be trying to detect running on an older kernel and exiting relatively cleanly.
If it's necessary to to any check at all before concluding that it's safe to call a function, I don't see the difference. Checking a magic number in one place seems no better than checking for a version number in another place, AFAICT.
Something like AUXV would have seemed cleaner to me; but that's just preference.
Having a faulting instruction doesn't permit the program to abort cleanly ahead of time (unless you check in advance -- in which case you're really back to a magic number again).
This matters if constructors might do things like screwing up the terminal -- if so, the chance to un-screw thing up should be offered to the program before it exits.
Possibly constructors should never do things like that, in which case these concerns don't apply. I don't know what the official line is regarding what kind of things global constructors should and shouldn't do.
If I understand correctly that's the whole point of abort() - if they need to tidy up then they should be handling SIGABRT.
Also, remember this whole discussion is just to print a message and exit nicely in the case of someone using a currently incredibly rare function on an old kernel!
I'd say we want to notify the operating environment and/or the user. This may be realised by writing some text to stderr, but that's not useful in the context of GUI environments.
Yes it is; exiting with a non-zero return value and writing to stderr is perfectly normal - whatever launched it can go and display that text. (Or as I say trapping SIGABRT).
I am not suggesting that we should engineer a special solution to that problem here, so long as we don't defeat potential solutions either. For now, it doesn't like any of the proposals risk that though.
Dave