I'm looking for pointers to places to look (and especially documentation,
if it exists) for how to directly access the VFS and its superblocks, and
how to create a superblock private to my own structure.
The first part is basically this: I want to be able to create syscalls
parallel to the normal FS calls (e.g., open()) that do not go through the
normal dentry-walking process but instead operate on the virtual device
ID. I imagine this would be accomplished by directly invoking the
function pointers within a VFS superblock structure. How can I gain access
to the superblocks, while maintaining the appropriate locking and so forth
within the VFS? So, how can I access all currently-mounted filesystems
without going through the normal path-parsing interface so I can access
each filesystem irrespective of any other mountpoints? (This would allow
me to access the directory under a mountpoint, and its contents.)
The second part is basically this: I want to be able to mount a filesystem
without using a mountpoint. I imagine I could use the VFS function pointer
for an FS driver with options directly instead of going through the
mount() syscall, which would give me a superblock structure I can maintain
and use myself without binding it to a directory. Is this correct? Again,
I want to maintain any sort of appropriate locking necessary. (This could
cause a problem if I obtain a superblock from a filesystem driver that
produces shared superblocks. Is there any way to detect this? Though
hopefully, if the driver is written appropriately, it would handle
concurrent operations from the VFS driver already, so since I wouldn't be
doing anything with it that the VFS wouldn't, it would still work as
expected.)
Really, what I'm trying to do is to access the Linux VFS tree directly
instead of by path/name strings. This is useful, to allow a package
manager to audit the permissions and contents of directories currently
used as mountpoints. I'm assuming some sanity checking is done, so that
when a mountpoint is in use, the directory underneath it is marked as open
so it cannot be deleted? (I wonder if that check is actually done, since
it's not expected for anything to access a directory used underneath a
mountpoint. But wouldn't the filesystem driver be able to remove the
directory itself, especially since that driver has no idea it even is a
mountpoint?)
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
