On Thursday 30 May 2024 07:42:09 GMT-3 Christian Brauner wrote: > Let me rephrase what I mean as I probably wasn't clear enough in my > first mail. My objection is mostly that I don't want us to start putting > stuff in there that's not generic. And yes, some statfs() fields might > make sense to put in statmount(). But I think stuff like "f_files" or > "f_ffree" is really something that's misplaced in statmount(). I'll take what I can get. My class's API exposes the total size of the filesystem (f_blocks), the bytes available and free (f_bfree and f_bavail), the block size and whether the filesystem is read-only. For the latter, I don't know if it's the same as MOUNT_ATTR_RDONLY. Keeping statfs() is not a problem. My biggest problem is matching the mounted filesystems from either mountinfo or listmounts() with what is actually visible in the system. For example, what happens if you mount something that makes a mountpoint invisible? Both df and the Qt class hide the entry too, but it was guess work until the mount IDs were exposed in statx(). -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Fleet Engineering and Quality
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
