[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YdNE6UXRT02135Pd@zeniv-ca.linux.org.uk>
Date: Mon, 3 Jan 2022 18:48:09 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: Walt Drummond <walt@...mmond.us>
Cc: aacraid@...rosemi.com, anna.schumaker@...app.com, arnd@...db.de,
bsegall@...gle.com, bp@...en8.de, chuck.lever@...cle.com,
bristot@...hat.com, dave.hansen@...ux.intel.com,
dwmw2@...radead.org, dietmar.eggemann@....com, dinguyen@...nel.org,
geert@...ux-m68k.org, gregkh@...uxfoundation.org, hpa@...or.com,
idryomov@...il.com, mingo@...hat.com, yzaikin@...gle.com,
ink@...assic.park.msu.ru, jejb@...ux.ibm.com, jmorris@...ei.org,
bfields@...ldses.org, jlayton@...nel.org, jirislaby@...nel.org,
john.johansen@...onical.com, juri.lelli@...hat.com,
keescook@...omium.org, mcgrof@...nel.org,
martin.petersen@...cle.com, mattst88@...il.com, mgorman@...e.de,
oleg@...hat.com, pbonzini@...hat.com, peterz@...radead.org,
rth@...ddle.net, richard@....at, serge@...lyn.com,
rostedt@...dmis.org, tglx@...utronix.de,
trond.myklebust@...merspace.com, vincent.guittot@...aro.org,
x86@...nel.org, linux-kernel@...r.kernel.org,
ceph-devel@...r.kernel.org, kvm@...r.kernel.org,
linux-alpha@...r.kernel.org, linux-arch@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-m68k@...r.kernel.org,
linux-mtd@...ts.infradead.org, linux-nfs@...r.kernel.org,
linux-scsi@...r.kernel.org, linux-security-module@...r.kernel.org
Subject: Re: [RFC PATCH 0/8] signals: Support more than 64 signals
On Mon, Jan 03, 2022 at 10:19:48AM -0800, Walt Drummond wrote:
> This patch set expands the number of signals in Linux beyond the
> current cap of 64. It sets a new cap at the somewhat arbitrary limit
> of 1024 signals, both because it’s what GLibc and MUSL support and
> because many architectures pad sigset_t or ucontext_t in the kernel to
> this cap. This limit is not fixed and can be further expanded within
> reason.
Could you explain the point of the entire exercise? Why do we need more
rt signals in the first place?
glibc has quite a bit of utterly pointless future-proofing. So "they
allow more" is not a good reason - not without a plausible use-case,
at least.
Powered by blists - more mailing lists