Role : BQuery support

Indexer: this maintains a BFS-like attribute index, and provides field-expedient support for BQuery. This is a VFS plug-in which sits on top of another one (typically NTFS-3g) and snoops on file operations directed to that underlying FS, looking for ops...

1. related to xattr
2. related to writing (or deleting) them rather than reading them, and maintains an index as a 'hidden file'.

That index can then be queried, speaking a "protocol" common to our re-implementation of BQuery.

Implementation: This uses "pure" Genode code, without dependancies on libc.lib.so or haiku.lib.so, so that we may live in a vfs_server and not just in an app's VFS.

Read on for implementation overview:

vfs_indexer.cpp

The actual VFS plug-in that interfaces with Genode's vfs system, and "maps" file system requests to IndexStore operations.

class BufIO

A data buffer that can hold a nul-terminated string (as Haiku's BString does) and is used as such for holding the (textual) Index ; and it may also hold binary data (as Haiku's BMallocIO) and is used as such for query results, which contain several embedded '0' characters to delimitate result entries.

class IndexStore

Provides hooks called by the VFS plug-in, which then call appropriate actions in SlotIO.

class SlotIO

Applies a certain (textual) format to the master Index. Can lookup a slot by file path, or iterate over the whole set, providing their attributes for matching purposes.

class SlotItem

Assists SlotIO in making changes to the Index: generally, an index entry (slot) is parsed into a SlotItem (and removed from the master Index), modified, and then re-inserted at the end of the Index.

This happens to be the more complex class of the lot, because it handles not only the Index maintenance role, but also the Index querying role, meaning it must be able to parse "query predicates" which include kinda-regular-expressions like e.g.:

(Audio:Artist=="Pink*Floyd")

Overview diagram

Once the attribute indexer is integrated into a full-fledged system, we get the following fairly deeply-layered structure ; arrows are labelled when they are on transit routes for file paths that include "dot paths" (ioctl-like extended attributes access) like "/boot/Music/thewall.mp3/.xattrs":

down
"App"

arrow
SKit: box "Storage Kit" "(produces dot-paths)" fit

move right from last box.e
move down
LibC: oval "libc" fit
arrow from SKit.se to LibC.nw  "dot-paths" aligned below

#+ add "Media Kit" box above the libav one...

move right from LibC.e
move up
LibAV: oval  "libav" "audio playback" fit
arrow <- from LibC.ne to LibAV.sw

move down to LibC.s
arrow  "dot-paths" aligned below

Vfs: oval "vfs" fit
move left from Vfs.w
move down
#arrow  "dot-paths" aligned below
#arrow from LibC.s

Idx: box "indexer" bold "plug-in" "(snoops on dot-paths)" fit thick fill Bisque
arrow  <-  from Idx.n to Vfs.s  "dot-paths" aligned below

move right from Vfs.e
move down

Ntfs: oval "FUSe NTFS" "plug-in" "(knows dot-paths)" fit
line from Vfs.s to Ntfs.n

arrow from Idx.e to Ntfs.w "dot" "paths"

#arrow
move to Ntfs.s
arrow

oval "lib-ntfs-3g" fit
arrow "via" aligned "libc" aligned

oval "Block dev" fit
arrow

oval "ahci_drv" fit