On Tue, Feb 05, 2019 at 06:09:39PM +0100, Stanislav Brabec wrote: > Dne 05. 02. 19 v 10:00 Karel Zak napsal(a): > > On Mon, Feb 04, 2019 at 05:38:56PM +0100, Stanislav Brabec wrote: > >>> If we will keep the fstype lists in the code than we can use it as > >>> the first attempt, if the name is not in the list than use your > >>> heuristic. > >> > >> It makes sense. > > > > Note that source path may be a relative path without any '/'. It's > > very unusual, but possible. > > I am aware of the fact that the driver can provide anything. Do we have any examples, where kernel or FUSE driver provides relative source path? This is mount(2) syscall feature; for example I have "simple_mount", just main() with mount(2) call: # cd /dev # simple_mount sdc /mnt/test ext4 1 # grep sdc /proc/self/mountinfo 530 94 8:32 / /mnt/test ro,relatime shared:275 - ext4 sdc ro,stripe=512 ^^^ > I am just working on a list of all pseudo file systems available in > the basic openSUSE repositories. Currently I have ~20 FUSE file > systems to inspect. > > We also may have two lists: One list of pseudo file systems, second > list of obscure pseudo file systems (that don't use relative paths). > If the source does not start with "/" and file system is not in one > of these lists, mount will return error. I can imagine that we can > move this list from code to /etc/libmount/pseudofs.d/. Some filesystems classification is already in /proc/filesystems. The problem is that the list is incomplete (contains already loaded filesystems only). Maybe we need a generic filesystems classification rather than pseudo-filesystems specific list. We also keep in the code table to convert magic numbers to FS name (see mnt_statfs_get_fstype()). What about /etc/libmount/fs.d/ for arbitrary filesystems and in the files keep all the hints: <name> <type> <magic> for example: autofs nodev 0x0187 cifs netfs 0xff534d42 The another possibility is not call mnt_resolve_path() on mount output. The problem is that we need mnt_fs_is_pseudofs() on another places like fstrim. Karel -- Karel Zak <kzak@xxxxxxxxxx> http://karelzak.blogspot.com