VFSCONF(9)

πŸ“¦ version 15.1, in freebsd 14.5, freebsd 15.1

πŸ¦‹ NAME πŸ¦‹

vfsconf β€” vfs configuration information ✨

and yes bestie, this whole page is VFSCONF(9) β€” section 9, the kernel developer's manual. we are literally in the kernel trenches now πŸ‘‘


🌸 SYNOPSIS 🌸

okay so first, the includes, because of course:

#include <sys/param.h>
#include <sys/mount.h>

then the three functions, exactly like this, no freestyling:

int
vfs_register(struct vfsconf *vfc);

int
vfs_unregister(struct vfsconf *vfc);

int
vfs_modevent(module_t mod, int type, void *data);

πŸ’– DESCRIPTION πŸ’–

so the whole vibe is this: every single file system type the kernel knows about has a vfsconf structure, and that structure holds all the info you need to create a new mount of that file system type. it's the little info packet. main character energy for a struct, honestly πŸ’…

πŸŽ€ the struct itself πŸŽ€

struct vfsconf {
        struct  vfsops *vfc_vfsops;     /* file system operations vector */
        char    vfc_name[MFSNAMELEN];   /* file system type name */
        int     vfc_typenum;            /* historic file system type number */
        int     vfc_refcount;           /* number mounted of this type */
        int     vfc_flags;              /* permanent flags */
        struct  vfsconf *vfc_next;      /* next in list */
};

copy it character for character, bestie, this is not a vibe-based struct πŸ™ˆ

πŸ¦‹ what happens when you mount πŸ¦‹

when a new file system gets mounted, mount(2) does a lookup of the vfsconf structure by its name, and if it's not already registered, it attempts to load a kernel module for it. the file system operations for the new mount point are taken from vfc_vfsops, and mnt_vfc in the mount structure is made to point directly at the vfsconf structure for the file system type. the file system type number is taken from vfc_typenum, which was assigned back in vfs_register(), and the mount flags are taken from a mask of vfc_flags. every time a file system of a given type is mounted, vfc_refcount gets incremented. counter goes brrr, no cap πŸ”₯

πŸ’… the three functions πŸ’…

  • vfs_register() β€” takes a new vfsconf structure and adds it to the list of existing file systems. if the type hasn't already been registered, it gets initialized by calling the vfs_init() function in the file system operations vector. it also updates the oid's of any sysctl nodes for this file system type so they match the newly assigned type number. slay ✨
  • vfs_unregister() β€” unlinks vfc from the list of registered file system types, but only if there are currently no mounted instances. and if the vfs_uninit() function in the file systems initialization vector is defined, it gets called. bye bestie πŸ‘‹
  • vfs_modevent() β€” registered by VFS_SET() to handle the loading and unloading of file system kernel modules. in the case of MOD_LOAD, vfs_register() is called. in the case of MOD_UNLOAD, vfs_unregister() is called. conditional energy fr fr πŸ’€

⭐ RETURN VALUES ⭐

  • vfs_register() β€” returns 0 if successful; otherwise, EEXIST is returned, which means the file system type has already been registered. not me showing up already on the list 😭
  • vfs_unregister() β€” returns 0 if successful. if no vfsconf entry can be found matching the name in vfc, EINVAL is returned. if the reference count of mounted instances of the file system type is not zero, EBUSY is returned. and if vfs_uninit() is called, any errors it returns will be returned by vfs_unregister(). errors on errors, periodt 🫢
  • vfs_modevent() β€” returns the result of the call to vfs_register() or vfs_unregister(), whatever the case. just passing the result straight through, iconic 🌟

🌈 SEE ALSO 🌈

go read those next bestie, i'll wait πŸ’œ


πŸ‘‘ AUTHORS πŸ‘‘

this manual page was written by Chad David <davidc@acns.ab.ca>. iconic of him, honestly πŸŽ€


and that's the page!! this lil beauty is from Debian, dated June 16, 2013, and it's VFSCONF(9) β€” now go mount something responsibly, bestie πŸ’…βœ¨πŸ“

πŸ“¦ where this page comes from