From owner-freebsd-hackers@freebsd.org Wed Aug 26 23:13:05 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 28BA93C0371 for ; Wed, 26 Aug 2020 23:13:05 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BcM8w4Gkpz3ZSP for ; Wed, 26 Aug 2020 23:13:04 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 07QNCuk1033757 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 27 Aug 2020 02:12:59 +0300 (EEST) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 07QNCuk1033757 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 07QNCtO7033756; Thu, 27 Aug 2020 02:12:55 +0300 (EEST) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Thu, 27 Aug 2020 02:12:55 +0300 From: Konstantin Belousov To: J David Cc: freebsd-hackers@freebsd.org Subject: Re: pidfile_open() usage in "mount" Message-ID: <20200826231255.GW2551@kib.kiev.ua> References: <20200826144013.GV2551@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 4BcM8w4Gkpz3ZSP X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 23:13:05 -0000 On Wed, Aug 26, 2020 at 01:13:24PM -0400, J David wrote: > On Wed, Aug 26, 2020 at 10:40 AM Konstantin Belousov wrote: > > It is possible that both pidfile_open() and the new function would share > > some significant amount of code. > > Not as much as one might hope, it looks like. There's already a > pidfile_read() function that isn't exported, so that helps. And it > looks like it might be worthwhile to pull out some of the > path-handling code to a common static function. But if for no other > reason than the O_WRONLY|O_TRUNC flags, the code necessarily diverges > pretty hard after the flopen/flopenat (depending on version). > > Would the right approach to this look something like: > > - New static function: int pidfile_real_open( const char *pathp, > mode_t ) that opens the right file, using the code & logic from lines > existing pidfile_open() (pidfile.c lines 105 - 147 in HEAD). > - Modify pidfile_open() to use pidfile_real_open() > - New public function: int pidfile_get( const char *pathp, pid_t > *pidptr, int ndelay ) returns 0 on success, EWOULDBLOCK (if ndelay is > nonzero and lock fails) or ENOENT (if pidfile does not exist). > Basically a wrapper around pidfile_open_int() and pidfile_read(). Usual error for timeouts is ETIMEDOUT. > > Notes: > - pidfile_real_open: don't love the name; not sure if there is a > naming convention for static functions that are called by public ones. > - pidfile_real_open: different versions will be need for 12/HEAD and > pre-12, due to lack of flopenat() in earlier releases. Do not bother with anything but HEAD for now. MFC would be next problem after the code is in HEAD. > - pidfile_get: returns error value directly as I think the general > move is away from returning -1 and setting errno in libraries like > this I believe the consistency is better than following the latest trends, and I am not sure that following pthread* model there gives any benefits. > - pidfile_get: ndelay would basically control the decision whether to > skip (if nonzero) the nanosleep loop structure around pidfile_read, as > happens in pidfile_open(). Probably not needed in most cases, but > I've been bitten by unskippable sleeps before in the weirdest places, > so why not? > - pidfile_get: Would rather call this pidfile_read but that's taken. > Since it's static though, could rename pidfile_read to > pidfile_real_read (or whatever else is conventional, same as > pidfile_real_open) and call this pidfile_read. That's my preference, > but it's hard for me to tell what's actually better and what just > looks better to me. > > If this all sounds OK, it shouldn't take me too long to come up with a > patch and corresponding test(s). It is too impractical to review a change by textual description instead of the diff. Write the patch, put it into FreeBSD phab https://reviews.freebsd.org and then you get the feedback.