Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 03 Jul 2025 13:00:27 +0200
From:      Olivier Certner <olce@freebsd.org>
To:        Konstantin Belousov <kostikbel@gmail.com>
Cc:        freebsd-current@freebsd.org
Subject:   Re: RFC: checking file systems support UF_HIDDEN, UF_SYSTEM
Message-ID:  <2410567.gG0HsuGxDd@ravel>
In-Reply-To: <aGZSh4rvXfLbnG-3@kib.kiev.ua>
References:  <CAM5tNy5eoY5f-fo9BKc4v34XKXF6%2B6Ae7Zpq=FH7owaSRYSHmw@mail.gmail.com> <4214798.O2WMGSuNBG@ravel> <aGZSh4rvXfLbnG-3@kib.kiev.ua>

index | next in thread | previous in thread | raw e-mail

[-- Attachment #1 --]
> It is not the right usage of the MNT_ flags. They are for feature
> controlling, not for the feature reporting.

That is not the case today (MNT_LOCAL, MNT_QUOTA, MNT_ROOTFS, MNT_USER, etc.). I also would like this to become true at some point.

> VOP_PATHCONF() is exactly for reporting some mnt features.

No, it is to report features that depend on a path.  It can be (ab)used to report mount features (calling it on any file inside the mount), but that obfuscates the fact that an information is per-mount, whereas statfs()/statvfs() are exactly designed for per-mount information.

> 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.

I don't disagree.  That said, at some point, we'll have to dodge the bullet, including separating control flags from report ones in the MNT_* namespace (and provide compat' functionality), and probably extending control flags with a second 64-bit field.

I suspected from the start that that was the main reason behind you recommending VOP_PATHCONF().  My point here is that it is a slightly non-optimal design choice (as explained just above) that will stay and was made out of a practical issue that anyway will have to be solved at some point, and I find this a bit unfortunate.  Solving the issue now is certainly much more work, and in any case I didn't mean to object to not doing it now.  But if someone(tm) wants to do it now, that would be great (perhaps me, but not sure yet).

Regards.

-- 
Olivier Certner
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----

iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmhmYssACgkQjKEwQJce
Jic5JA//ZlXKcJVUSvQ0dUuWbH4/unrTLJtbDvwhRhX4ifskCOPHHCIpKuNr3Qq6
MbLpc+jHkl8q8Xik+ik2gWhZdzqKSiJURSez8ccI9YQ0O44yrtkNigTcz9tjAt+O
Svc7JMujxNI70dXdA0mYRDKgcqvU8SU1Tm2goPQWX9T7Mhd9K/4g9q3vLrUdxX6h
uWjjVqGacvV238PA7sz+USYTcaQaoO/lOw8xNoKuWkQGopC1myd1DeKWYKaykFZQ
16iPHEakl2GJMStjtDl5bSTZS54wwYCiowWvCN3Vq05qN4ULythBLUlmSW/BT/z9
m1lgYN+zGoWe1Ers83pPyjdpQAFGHNL/V/iEwoulkRSGlKbPQvbC8KJ9aTPRPsZS
7VxWKsPvdax2F+1NIiQwEALDk1hfer6vKukEJgJE3YD7gMsTI8QY2aaZvpOFEvba
T0BYwrMEFhk4xsc6ify31AAu3KyydmkQqIoOz4gdjuxX3tsqwuSss7TRGAopEN3l
p+58TmI+9wyLf8DvXXvAbcRm3Njw0uzFLgMVXaw9SM9BwjAHoRiL/sUl7/UiJ8Fk
krfrgQU5R7QBv4Ye9lT/46MRx8aQppThfA0JDviNcyjejTuO82fsUQ7woliR+O+4
dQb/vCu1bj9teDiCr0jYb5TV0DYr7n8dKijnADgUNTWoF0RPCUw=
=NivB
-----END PGP SIGNATURE-----
home | help

Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2410567.gG0HsuGxDd>