[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZmMptdPt_Zw9Xrlt@finisterre.sirena.org.uk>
Date: Fri, 7 Jun 2024 16:39:33 +0100
From: Mark Brown <broonie@...nel.org>
To: Dev Jain <dev.jain@....com>
Cc: alx@...nel.org, linux-man@...r.kernel.org, mingo@...nel.org,
tglx@...utronix.de, mark.rutland@....com, ryan.roberts@....com,
suzuki.poulose@....com, Anshuman.Khandual@....com,
DeepakKumar.Mishra@....com, AneeshKumar.KizhakeVeetil@....com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] signal.7: Clearly describe ucontext kernel dump to
userspace
On Fri, Jun 07, 2024 at 06:01:18PM +0530, Dev Jain wrote:
> .I ucontext_t
> -object that is pointed to by the third argument of the signal handler.)
> +object that is pointed to by the third argument of the signal handler.
> +We emphasize on the fact that this object contains context information
s/We emphasize on the fact that/Note that/
feels more idiomatic.
> +of the thread, present before jumping into the handler; the set of
> +blocked signals for the current thread would be updated from struct
s/would/will/
> +sigaction only after
> +.I ucontext_t
> +has been dumped to userspace. This semantically makes sense since the
> +context for which the signals have been blocked, remains only during
> +execution of the handler.)
I'd drop the "this semantically makes sense" and reword the last bit to
be something like "The ucontext reflects the state at the time the
signal is delivered rather than in the handler" for idiom reasons.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists