From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 89ACAA053E; Mon, 27 Jul 2020 21:44:26 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0359D2C6E; Mon, 27 Jul 2020 21:44:26 +0200 (CEST) Received: from mail-pj1-f68.google.com (mail-pj1-f68.google.com [209.85.216.68]) by dpdk.org (Postfix) with ESMTP id 8C0D02B8D for ; Mon, 27 Jul 2020 21:44:24 +0200 (CEST) Received: by mail-pj1-f68.google.com with SMTP id k71so10243207pje.0 for ; Mon, 27 Jul 2020 12:44:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=mGhpgEM39/b6YzkmeqbrHCUyUT7NoYMF+BYIDclSuWk=; b=Wee6NgRtpeS5MkIX6G8i/T/KA51Zk7ZpZ6Vh8u6B3X+3b/hDCtdJAIKWFU2lGI+43Q DmNi/Xy1ZN/PfNmByQAKoI0dBp7WYUYVtxZ92AAs+FKMNUe9loFoQrWcuwo7Sq7vtCuz rpqSexeave0cV8SRqvjJKSqlJ6o25VExXkAGoDG3g3M6zRy4g4+ahE03K6R64YTbMRjv 0ExREI2UJUeATGG1Y141KoMj77yZcD6jWW8lH8JrHDZhHYc4tf9bPX4tOXBDC8/LVbNW ODoX2uUReILOICC9wboBnO2dM6HgLYRsMvFWJ40eR9ogTfTYRbhv88Qtn1GvTHurUMxb mZ/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=mGhpgEM39/b6YzkmeqbrHCUyUT7NoYMF+BYIDclSuWk=; b=bygfV7RHQWO+y6hU8m7qR0OW94JVxDKEkqnuVhso1pv6t9fNRCe8ho6gvjNsxEwTYP z9wGx+1uLhKch8RkgWsmr5fuBgayX7IdgSEopXLEDHfe4+a6MHn0h1SuQ3oFjv+j+wtS 8E2PQoRcwI8viEv0kj3GIxbFOYdVjnq/0rkig7OAmhotBIdqNC9dGxJW3Ldnlxx05BKc C5PbGdRSqy1kXuRIL/x4xGpWBcFlvvMBtXw166h1pQl+9tr7rnwGPf5VMBnJMBnojFM6 4VUb7e4+urqpbYaRpMSs5hdvzfxGxuQICf6qIrDn8wGszhEHU4VXHilPT5HfrSdBNQDZ gEGw== X-Gm-Message-State: AOAM531fNVtRHAtAKJ+tHXxXp+Q4dIr+7kCECQjXIgKth26TJdN0Ex16 4aFZ7nkVGntDa5MgsvvncCmRSw== X-Google-Smtp-Source: ABdhPJx88Ie1ChrbTx6beTzAZnNTESPuicFCNwSt0UIQKleeS9jpTxMcrQsgaELjb0Yivo3vp0en+A== X-Received: by 2002:a17:90a:14a5:: with SMTP id k34mr823304pja.37.1595879063728; Mon, 27 Jul 2020 12:44:23 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id gf24sm405852pjb.4.2020.07.27.12.44.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Jul 2020 12:44:23 -0700 (PDT) Date: Mon, 27 Jul 2020 12:44:15 -0700 From: Stephen Hemminger To: Morten =?UTF-8?B?QnLDuHJ1cA==?= Cc: , Message-ID: <20200727124415.79e75f39@hermes.lan> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C61166@smartserver.smartshare.dk> References: <20200422010156.1956-1-stephen@networkplumber.org> <20200714235810.5286-1-stephen@networkplumber.org> <98CBD80474FA8B44BF855DF32C47DC35C61166@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH] net/tap: avoid using SIGIO X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Mon, 27 Jul 2020 15:19:32 +0200 Morten Br=C3=B8rup wrote: > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Stephen Hemminger > > Sent: Wednesday, July 15, 2020 1:58 AM > >=20 > > SIGIO maybe used by application, instead choose another rt-signal. > > Linux allows any signal to be used for signal based IO. > > Search for an unused signal in the available rt-signal range. =20 >=20 > Just an observation. Feel free to ignore at your convenience: >=20 > The problem is the same as for SIGIO if the application sets up its own s= ignal handler after this, and uses some hardcoded rt-signal that happens to= be the one found to be free. >=20 > Unless the application doesn't use a hardcoded rt-signal, but also search= es for an unused one. >=20 > So perhaps the "search for unused rt-signal" should be exposed as a gener= ic support function for the application (and this driver) to use. There is no safe way to use a signal deep inside DPDK in a driver. This is not the kind of thing that should be exposed to the application. The algorithm for finding an RT signal conforms to the recommended policy o= n the signal(7) manual page. programs should never refer to real-time signals using hard- coded numbers, but instead should always refer to real-time signals using the notation SIGRTMIN+n, and include suitable (run-time) checks that SIGRTMIN+n does not exceed SIGRTMAX. The application should be following the proscribed policy on the man page. If it doesn't it is broken.