[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    Re: pidfile_open() usage in "mount"
From:       Konstantin Belousov <kib () freebsd ! org>
Date:       2020-08-26 23:12:55
Message-ID: 20200826231255.GW2551 () kib ! kiev ! ua
[Download RAW message or body]

On Wed, Aug 26, 2020 at 01:13:24PM -0400, J David wrote:
> On Wed, Aug 26, 2020 at 10:40 AM Konstantin Belousov <kib@freebsd.org> 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.
_______________________________________________
freebsd-hackers@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
[prev in list] [next in list] [prev in thread] [next in thread]