I am doing some proof of concept for a virtual filesystem extension. I wrote the following
email to the linux filesystem mailing list.
Hello mailing list members,
I am not sure about the best name, but I am sure it is sthg. very usefull. So I will call it mobifs, hope you do not mind 
I am also not sure if there is sthg. like that out there, but based on my 15 years of linux experience I never met sthg. like what I would like to talk about.
What I would like to have on my linux boxes is to access data the following way:
#>cat /dev/sda1@/partition1/etc/inittab@/defaultranlevel #usecase 0
#>cat /data/xmlfiles/apsettings.xml@xml/main/entry1/subentry/value #usecase 1
#>cat /data/xmlfiles/apsettings.xml@/main/entry1/subentry/value #note @ instead of @xml #usecase 2
#>cat /data/images/linux.img/@/partition1/etc/dhcpd/dhcpd.conf@group/next-server#note twice the @ #usecase 3
driver to read xml files. If yes, it will call the driver and pass the rest of the string to it. The xml driver
will interpret the path request and output the necessary entry. If there is nothing specified like in usecase0 (note annoying tmp. mount not needed!!!)mobifs will try to guess, and if he finds a matching filetype (like the file command or mount does) it would pass the path to the driver if there is any driver registered for that. Drivers can be partition readers (do not know oficial technical name
:)), existing filesystem drivers etc. It should be possible to have kerenel drivers and userspace drivers.
It seems rather logical that for reading filesystems one would use kernelspace drivers, and
for trivial file mapping operations userspace program would fit better.
Usecas0 has twice @. This should mean double “redirection” or piping. Mobifs should help to feed the output of one driver with the input of next one, etc. In case of usecase 0, the one driver would read the filesystem on sda1, and feed the read of the driver that is able to read inittab files.
If sthg. like that would become to being, I would see its evolution as 2 main steps: first create
read only support, and then add write support. The same would happen with the drivers…
I was thinking about this the last few days, started to hack around the kernel, but before going
to the wrong direction, I wanted to ask more experienced people about what and what not to do!
for some more imagined usecases, see the PS.
rgrds,
mobi phil
P.S.
#>cat /databases/mysqldatabase/db.sql@mysql/tables/table1/2345/rowname
#>cat /databases/mysqldatabase/db.sql@mysql/tables/table1/rowname/1232
#>cat /databases/mysqldatabase/db.sql@mysql/tables/table1/rowname
#>cat /xxx/xx/xx/xx/elfimage@elf/symbols
#>cat /sourcecode/cpp/thismodule/thatfile.h@cpp/methodist
#>cat /sourcecode/cpp/thismodule/thatfile.h@cpp/includelist
#>cat /sourcecode/cpp/thismodule/thatfile.cpp@cpp/methods/thatmethod
#>cat /sourcecode/cpp/thismodule/thatfile.h@cpp/methodist
#>tail -f /var/log/messages@grep/error #maybe this is less usefull