On 1/16/23 15:54, Daniel Colascione wrote: >> On Mon, Jan 16, 2023 at 3:30 PM Daniel Colascione <dancol(a)dancol.org> >> wrote: >> >> This sounds great, but how is it going to get made? > Someone has to do it. 😄 I've been thinking about adding this mechanism for a > few years, but haven't had time so far. I suppose the first step would be > raising the subject on libc-alpha and LKML. Both places (especially the > former) tend to be conservative, so it'd be prudent to settle in for a long > debate. > >> And is the kernel amenable to this in the first place? > I don't think anyone's asked. I don't see a reason (at least a reason based > on the technical merits) for the kernel to be opposed, but the Linux world > isn't known for the tight coordination between the kernel, libc, and managed > runtimes that this mechanism would require. > > I'm more worried about libc, to be honest. The last time [1] I proposed > improvements involving signal handling, libc-alpha's response was essentially > "No, absolutely not, we're not going to touch a thing related to signals > because nobody should be using signals for any purpose whatsoever". I don't > think this is a terribly realistic perspective on the part of libc-alpha, > especially given how often signals are, in fact, used productively in the > real world. I hope that they might be a little more moderate when it came to > unwinding.
Could the vDSO do the unwinding? > [1] https://sourceware.org/legacy-ml/libc-alpha/2018-03/msg00214.html -- Sincerely, Demi Marie Obenour (she/her/hers) _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue