From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 230E3C433F5 for ; Tue, 4 Jan 2022 01:01:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230044AbiADBBM (ORCPT ); Mon, 3 Jan 2022 20:01:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40534 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231537AbiADBBM (ORCPT ); Mon, 3 Jan 2022 20:01:12 -0500 Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8E079C061785 for ; Mon, 3 Jan 2022 17:01:11 -0800 (PST) Received: by mail-lf1-x12f.google.com with SMTP id p13so41936215lfh.13 for ; Mon, 03 Jan 2022 17:01:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drummond.us; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=FhCziXSDIVqEHeqdeTNAEnAmaxA2oTV83a7FYCmISUs=; b=F3tiUyofNHmKDjVKk2XPN3VpXToJGh87luR1ns6i8fTdNqA4z8KYh9xx+TznQjoZjx 58TqlIC/Vj4aNPJdMn0Qd4bZbVRnPNzaiJsnWmPeQALXVgD8VLO6jDj+VHazpPTPSB/1 HWADwSJX1ZZu/dty1WaUP2KxY3Sw8VXiOiuQVgSrT0HZK6iCenP0DqyTmiLJ/HLXpAkt XV2/Qm1/GSgSHGlTEcr7ZdTgUQFmUi8gJrn/bzNGljU+2Io9kcqa3WpeXo9FQyxn1hSi ZpXEpEI9CKyeqqjCKo8dnjdUhHcpVlmwW0nTMezbw0pCmHnuNbP25JEqrHIUEfMvPFzO WX5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=FhCziXSDIVqEHeqdeTNAEnAmaxA2oTV83a7FYCmISUs=; b=4M2rm8fPsABnAifrpTWSjSm0si2tdczDW58BgjCCZqz9585RF3u6v8a7irslhtWgp4 0rXNXc4hdTL9h9W71JZFU1oFTB915Py+RmnDoaNZxWIfNRHAXypM4hDkgNiF8VfAHoFC vLAAgVLcYPK1z4CLXvKWhNocA4hejELC/RGYJxW/SD4/cqwOUUG3wZ99gz1BAquS5DTQ omrufKaRq4Hks33jBODt3hb/GlxUumpuLy5dbEQVKFtjwFfYQLRAZfmH92urw/bmn3JJ WQPaZPU6uimKrLPO6rSr0x2BIylTn2xE2rjaWgl6EhE1A8YQyicBxX6QYfb4plX5lxf5 94nA== X-Gm-Message-State: AOAM530snInbPoJop7XA1mcWnyDqT78dqIBUCXOp8BhTy8ExJMi89XmH 32VmbO7fetYTIguvs2O/szPcrrNTPl/+2jjgp9mI1w== X-Google-Smtp-Source: ABdhPJwcgc1Ga1+rLCxU1YpJid0/47ry1/i0pez4n8tVA8yyD2kMd606iUiB5mCcPG+LT0NFgOGKtjbLaTH04xucoSo= X-Received: by 2002:a05:6512:2083:: with SMTP id t3mr41569950lfr.595.1641258069695; Mon, 03 Jan 2022 17:01:09 -0800 (PST) MIME-Version: 1.0 References: <20220103181956.983342-1-walt@drummond.us> In-Reply-To: From: Walt Drummond Date: Mon, 3 Jan 2022 17:00:58 -0800 Message-ID: Subject: Re: [RFC PATCH 0/8] signals: Support more than 64 signals To: Al Viro Cc: aacraid@microsemi.com, anna.schumaker@netapp.com, arnd@arndb.de, bsegall@google.com, bp@alien8.de, chuck.lever@oracle.com, bristot@redhat.com, dave.hansen@linux.intel.com, dwmw2@infradead.org, dietmar.eggemann@arm.com, dinguyen@kernel.org, geert@linux-m68k.org, gregkh@linuxfoundation.org, hpa@zytor.com, idryomov@gmail.com, mingo@redhat.com, yzaikin@google.com, ink@jurassic.park.msu.ru, jejb@linux.ibm.com, jmorris@namei.org, bfields@fieldses.org, jlayton@kernel.org, jirislaby@kernel.org, john.johansen@canonical.com, juri.lelli@redhat.com, keescook@chromium.org, mcgrof@kernel.org, martin.petersen@oracle.com, mattst88@gmail.com, mgorman@suse.de, oleg@redhat.com, pbonzini@redhat.com, peterz@infradead.org, rth@twiddle.net, richard@nod.at, serge@hallyn.com, rostedt@goodmis.org, tglx@linutronix.de, trond.myklebust@hammerspace.com, vincent.guittot@linaro.org, x86@kernel.org, linux-kernel@vger.kernel.org, ceph-devel@vger.kernel.org, kvm@vger.kernel.org, linux-alpha@vger.kernel.org, linux-arch@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-m68k@vger.kernel.org, linux-mtd@lists.infradead.org, linux-nfs@vger.kernel.org, linux-scsi@vger.kernel.org, linux-security-module@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: I simply wanted SIGINFO and VSTATUS, and that necessitated this. If the limit of 1024 rt signals is an issue, that's an extremely simple change to make. On Mon, Jan 3, 2022 at 10:48 AM Al Viro wrote: > > 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=E2=80=99s 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.