Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp4168405pxj; Tue, 11 May 2021 22:36:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxfRuW93i03ewo9gShNEwvkOnX/XryIIrfnpo/fAiO88eZukgdBUndCEEevknEBgDpT2igL X-Received: by 2002:a5d:9b86:: with SMTP id r6mr10580358iom.43.1620797770048; Tue, 11 May 2021 22:36:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620797770; cv=none; d=google.com; s=arc-20160816; b=V1jZ8x4zcFhj6zuz3qB/3Hqa0H+xnZulLLJhbYm4Uz3ytot8Uy8hBaSQLmtbROtq/L nBLGR+/2KY92YT0MAhL3wbURNSTtFDKU4qmJrbvlIyA9B8aXQo5sMRaFERkZos5GRrUY eKe9vVAihLhVGaclVqfFscPvS2zEaW1PEmIbIeqUGK/t5iGM7NAktWs/6rx6jCAo0MVi Kt8avzLM8swP62AYiMVWr6SkR+yF52XibkJ+LHS0ZKMYqHUmf68C+4AyXcDE7Ik6mlWW fSi7KAUoNDsnek4O2PxlSCSgEPiTOu8eqTr4pcwahq1VFPs+Z5jNT6/cQvAnwRxUfyhe XZKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=s/jQQhHfpGxrdEeTGGiDV6F1+nE1Fw6Ahu3m/kz21ug=; b=pssr/4mf6Z4epxdDtwhw4ceQHQ9GSGJ/VTT7Eyt1hoIyYgsfoPmlnIxCD00qsR/HZm Q9vymrYM1EMB14TqSYXqR8W3pf2XB0m/oXNI8SVgFmiaU7ovK7zTrA9zZF2QylO3wfFC ZSyF6/atOpm6Zpi5C7vNDHHaWYfqM5/JL+BY+QNyCtBc3CNfW5zEY5ISOHpGE49UrU1q 53dEQ4tUGUWe52Ft0imonX13HJFmP+3Om+gYWcY2hP7s127OGaRJ47oUzRpd8SRwz0ch fDf7kU4ilveJQKMcOsLARID3Ch5ufB4cyHjD7uEFNkQlMnTPA+JT4lYam805Dn86Zt6P w0iQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k8si25203784jav.68.2021.05.11.22.35.57; Tue, 11 May 2021 22:36:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230135AbhELFfJ (ORCPT + 99 others); Wed, 12 May 2021 01:35:09 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:52969 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230017AbhELFfI (ORCPT ); Wed, 12 May 2021 01:35:08 -0400 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 14C5Xual020758; Wed, 12 May 2021 07:33:56 +0200 Date: Wed, 12 May 2021 07:33:56 +0200 From: Willy Tarreau To: Mark Brown Cc: linux-kernel@vger.kernel.org Subject: Re: [PATCH] tools/nolibc: Implement msleep() Message-ID: <20210512053356.GA20749@1wt.eu> References: <20210511110159.57286-1-broonie@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210511110159.57286-1-broonie@kernel.org> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Mark, On Tue, May 11, 2021 at 12:01:59PM +0100, Mark Brown wrote: > +static __attribute__((unused)) > +void msleep(unsigned int msecs) > +{ > + struct timeval my_timeval = { 0, msecs * 1000 }; > + > + sys_select(0, 0, 0, 0, &my_timeval); > +} > + Just a quick question, is there any reason for not keeping most of the precision like this and allow applications to use it beyond 4294 seconds like this ? struct timeval my_timeval = { msecs / 1000, (msecs % 1000) * 1000 }; Another thing that comes to my mind is that sleep() returns the remaining number of seconds if the syscall was interrupted, and I think it could be very useful in small tests programs to do the same at the subsecond level in simple scheduling loops for example. Copying what we're doing in sleep() we could have this: if (sys_select(0, 0, 0, 0, &my_timeval) < 0) return my_timeval.tv_sec * 1000 + (my_timeval.tv_usec + 999) / 1000; else return 0; And since that's an inline function it will be optimized away if the result is not used anyway, resulting in the same code as the void version in this case. What do you think ? Thanks! Willy