therealkenc
commented
5 years ago This question isn't really well formed (or rhetorical), so I'm not even sure what a constructive answer would be here. DrvFS calls down to the underlying filesystem, and any filter driver on that filesystem can watch the operations fly by or intercept them as it sees fit. But you already know that, so that isn't the answer you are looking for.
If you mean, is there a way to intercept WSL's Linux-alike VFS calls.... well, "no". That wouldn't be NT filter driver naturally (wrong API). You know that already too. One could hypothesize an alternate-universe where there was either a WDK for WSL that provided hooks into WSL's VFS function pointers. Or, somewhat equivalently, provide some kind of loadable kernel module API from the WSL side, which is more-or-less a rerun of #1893 (message). Which got a "likely never happen" ... "though it would be pretty cool" ... "[closing] this out for now" from the devs.
In the interest of heading off more of these, #3865 remains a pretty valid question/ask. It remains open. Separately, up-voting the FUSE UserVoice is probably a good place to start, since it doesn't take a Sherlock Holmes degree of deductive reasoning to assume FUSE will come sometime before "expose internal WSL VFS API with WDK" arrives.
Is there such a thing as filter driver for DrvFS to intercept just the VFS calls coming from LXCORE . This can speedup the WSL linux apps tremendously when used with crossmeta without any further translation as it is already providing a POSIX file system XFS, EXT4 etc.
This is already done in Crossmeta Testing as it provides direct path using DeviceControl (ioctl) mechanism to its own programs and NTDLL api path for other programs.