From nobody Thu Sep 22 10:11:26 2022
X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
	by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MY9zj3Xwmz4cyVr;
	Thu, 22 Sep 2022 10:11:29 +0000 (UTC)
	(envelope-from mjguzik@gmail.com)
Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MY9zh3mVVz3mx7;
	Thu, 22 Sep 2022 10:11:28 +0000 (UTC)
	(envelope-from mjguzik@gmail.com)
Received: by mail-oi1-x231.google.com with SMTP id n83so11667103oif.11;
        Thu, 22 Sep 2022 03:11:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:references:in-reply-to
         :mime-version:from:to:cc:subject:date;
        bh=uEbQVJrpoAucl1qDegxUUZbC1B8IcdtzSSA7Dl+KPgA=;
        b=pwXohf1IIfB32slg9sJwSmIVmE1dNvkah5IA/oWKDYRazOCoFiOqI5Ov/5hHpjz7iP
         BBbz+mdyevcMCY1R/X3YDt3tgxXd3pKi+iLnPYbh5OGc50lowy06J86vq3RbaxHZfzN7
         coYcoJ7bUZDm27Sj5bZIFvcTDA6hmSACI72oaAQsGA0+9uxGrdCp1FN0wIEr53K2xSPV
         JrrbbwbAUUlQ097cbTeWI1loDNYONkB7yQyLO6e2tTY+YpkPjLK5sA99jL4i7PgIXFmP
         c7sGOwEw1tjHthbvMTKUcvAd0G2LvnfzSnNdyfT2N2/fl/MnvBfXTrGF7bqLxM3MI8jJ
         8tBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:references:in-reply-to
         :mime-version:x-gm-message-state:from:to:cc:subject:date;
        bh=uEbQVJrpoAucl1qDegxUUZbC1B8IcdtzSSA7Dl+KPgA=;
        b=RLkC/u5croNdSLPcmnKYwIWOyRB7RcPi7gRzm+Vj4x5bV0xR7S4VmwNN7yeMrsX3zr
         GjX+Jz4np4B9Irws+0BjCHMTYzEbVXWhPh8gtmhzyDaf1qkP6dGWlOjhIVzc8Co30QC6
         BlUzNIGSgHv5Ct5Ak850p71yKLFucCbOe5/VN7i/l2CV6W88L7nqTZS4t1l4ss1/adLt
         j+IeZRaTNBhIF48Y7hPNAKgABoCX2NmQc7Wnvn7J4bxXT1OE21SOdFiPAQqbeJjfkmny
         jG0Ef9CQ2cPB58AZVGWcZY7fcxcr7tGLtMFvqOQPGJvNCCUdFWlTIjg7XTsdhwN7OezL
         q44g==
X-Gm-Message-State: ACrzQf0h7Wss1dE2liGAaqO+ktOLsDlQE0Y8ouvl56cttjPkhL5dqQUN
	3ZnOUXteJqpEPi6xAERh+V7CWUz9OOzMIWs2YAZEfR0G
X-Google-Smtp-Source: AMsMyM4y7mU4MkUv5WjI6Q9FP1qUHb8oOKiB+XNOALCizPDx00lFu+3ePlfWpaN0tH1O3xmRCEet59nfbyRYcHcwlOw=
X-Received: by 2002:a05:6808:2390:b0:350:5c6b:5ef9 with SMTP id
 bp16-20020a056808239000b003505c6b5ef9mr1203281oib.96.1663841487552; Thu, 22
 Sep 2022 03:11:27 -0700 (PDT)
List-Id: Commit messages for the main branch of the src repository <dev-commits-src-main.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main
List-Help: <mailto:dev-commits-src-main+help@freebsd.org>
List-Post: <mailto:dev-commits-src-main@freebsd.org>
List-Subscribe: <mailto:dev-commits-src-main+subscribe@freebsd.org>
List-Unsubscribe: <mailto:dev-commits-src-main+unsubscribe@freebsd.org>
Sender: owner-dev-commits-src-main@freebsd.org
X-BeenThere: dev-commits-src-main@freebsd.org
MIME-Version: 1.0
Received: by 2002:a8a:352:0:b0:474:267f:5338 with HTTP; Thu, 22 Sep 2022
 03:11:26 -0700 (PDT)
In-Reply-To: <CAJ5_RoA4=NqQ-XZ52rJ7J1xJMUg2U=kB+7b_x5sLHXFsJGwVSg@mail.gmail.com>
References: <202209192009.28JK924f075123@gitrepo.freebsd.org> <CAJ5_RoA4=NqQ-XZ52rJ7J1xJMUg2U=kB+7b_x5sLHXFsJGwVSg@mail.gmail.com>
From: Mateusz Guzik <mjguzik@gmail.com>
Date: Thu, 22 Sep 2022 12:11:26 +0200
Message-ID: <CAGudoHF1peBhw03ucSv+8eGdkC5=Fq_sOjPWjjd6iqtu44qgDw@mail.gmail.com>
Subject: Re: git: 2c2ef670a79b - main - pseudofs: use the vget_prep/vget_finish
 idiom
To: Benjamin Kaduk <bjkfbsd@gmail.com>
Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, 
	dev-commits-src-main@freebsd.org
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4MY9zh3mVVz3mx7
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=pwXohf1I;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of mjguzik@gmail.com designates 2607:f8b0:4864:20::231 as permitted sender) smtp.mailfrom=mjguzik@gmail.com
X-Spamd-Result: default: False [-2.00 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-0.997];
	NEURAL_HAM_LONG(-0.55)[-0.553];
	NEURAL_SPAM_SHORT(0.55)[0.546];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::231:from];
	FREEMAIL_TO(0.00)[gmail.com];
	MLMMJ_DEST(0.00)[dev-commits-src-all@freebsd.org,dev-commits-src-main@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	FREEMAIL_FROM(0.00)[gmail.com];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

On 9/19/22, Benjamin Kaduk <bjkfbsd@gmail.com> wrote:
> On Mon, Sep 19, 2022 at 1:09 PM Mateusz Guzik <mjg@freebsd.org> wrote:
>
>> The branch main has been updated by mjg:
>>
>> URL:
>> https://cgit.FreeBSD.org/src/commit/?id=2c2ef670a79b7f8fa84796a04885a3f76c914762
>>
>> commit 2c2ef670a79b7f8fa84796a04885a3f76c914762
>> Author:     Mateusz Guzik <mjg@FreeBSD.org>
>> AuthorDate: 2022-09-19 20:07:10 +0000
>> Commit:     Mateusz Guzik <mjg@FreeBSD.org>
>> CommitDate: 2022-09-19 20:08:40 +0000
>>
>>     pseudofs: use the vget_prep/vget_finish idiom
>>
>>
>
> Picking an arbitrary commit to reply to: could you please add a bit more
> detail about the "why" to commit messages in the future?
> Having looked a little bit, it seems that this would be "as part of the
> broader effort to remove the vnode interlock [from a specific class of
> operations?]".  A pointer to a bigger-picture doc would be great as well.

The idiom at hand is over 3 years old now and employing it at this
point should not require a justification.

One can easily see not taking the interlock is faster both single- and
multi-threaded, which makes the change worthwhile regardless of
support for the flag in locking primitives going away or not.

So happens I'm going to keep the flag support in vget itself for the time being.

> I co-maintain an out-of-tree filesystem and commit messages like this make
> it really hard for me to get a handle on whether I need to do anything and,
> if so, where to start looking to find out what to do.  An overall project
> page would be a great reference, or even comment around the implementations
> that points to a key differential revision that implemented the core
> behavior.  One of the things that's been really nice about developing for
> the FreeBSD VFS in the past is how easy it is to determine what a
> filesystem implementation needs to provide, and I'd love to see us continue
> that tradition.
>

I'm definitely confused by this comment. VFS has rampant layering
violations, including wtfs like filesystems sneaking in their own
changes to cn_flags by literally or-ing into it mid-lookup (recently
fixed, see 5b5b7e2ca2fa9a2418dd51749f4ef6f881ae7179) or leaking their
internals out and consequently imposing completely unnecessary
restrictions on the layer (see a comment above vput_final for an
example).

That said, the changes I normally made are either backwards-compatible
or are guaranteed to blow up at compilation time (or worst case at
runtime with an assert).

I agree some form a general doc would be nice, but between spending
time writing one or actually getting things done, I chose the latter.

There are several filesystems which I have no intent in modifying
beyond bare minimum to keep them operational, thus general theme of
backwards compat will continue.

-- 
Mateusz Guzik <mjguzik gmail.com>