From nobody Thu Jul 03 09:51:03 2025 X-Original-To: freebsd-current@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 4bXsTw5B4Tz60Xfj for ; Thu, 03 Jul 2025 09:51:16 +0000 (UTC) (envelope-from kostikbel@gmail.com) 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 4bXsTw1fzDz3VLG; Thu, 03 Jul 2025 09:51:16 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 5639p3Jv040254; Thu, 3 Jul 2025 12:51:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 5639p3Jv040254 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 5639p3bQ040253; Thu, 3 Jul 2025 12:51:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 3 Jul 2025 12:51:03 +0300 From: Konstantin Belousov To: Olivier Certner Cc: freebsd-current@freebsd.org Subject: Re: RFC: checking file systems support UF_HIDDEN, UF_SYSTEM Message-ID: References: <4214798.O2WMGSuNBG@ravel> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4214798.O2WMGSuNBG@ravel> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Rspamd-Queue-Id: 4bXsTw1fzDz3VLG X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] On Thu, Jul 03, 2025 at 10:57:15AM +0200, Olivier Certner wrote: > > I suggest adding more _PC_XXX constants and use VOP_PATHCONF() to get the > > property of the specific mount point. You might query it on the root > > vnode and cache it somewhere. Also this information would become > > available to userspace due to pathconf(2). > > That works and is probably the path of least resistance. An alternative would be to export this information through statfs()/statvfs(), as probably no (sane) filesystem would support these file attributes only in some directories (in other words, this information is per-mount). However, to stay backwards-compatible, that would mean either defining new MNT_* flags or using some spares in 'struct statfs', and translating these into a new report flag for statvfs(). > It is not the right usage of the MNT_ flags. They are for feature controlling, not for the feature reporting. VOP_PATHCONF() is exactly for reporting some mnt features. Also, this namespace should not be used frivolously, we already had to extend flags to 64bit, and again we are not too far from exhausting it.