‫Understanding the VFX layer.
‫So what is the VSAT layer?
‫Well, firstly, VFW's stands for virtual filesystem, the virtual filesystem layer allows the kernel
‫to support an infinite amount of filesystems.
‫The virtual filesystem layer allows us to abstract out low level filesystem code such as reed operations,
‫right operations, open operations and so on.
‫The VSAT layer also allows filesystem functionality to be loaded or unloaded to the kernel at any time.
‫For example, the driver code for reading from the file allocation table can be unloaded from the kernel
‫when we are not using it.
‫This allows our kernel to be more memory efficient.
‫The vessel allows unlimited filesystems file system drivers can be loaded or unloaded on demand and
‫most importantly, the programming interface to the filesystems remains the same for all file systems.
‫It is completely abstracted out.
‫We talk to the VSAT layer in a unique way and it then decides which filesystem to pass on messages to.
‫This is the first layer.
‫So what happens when a disk gets inserted into our computer while our kernel will polish file system
‫that is loaded and ask if the disk holds a file system it can manage.
‫We call this resolve in the file system.
‫When a file system that can be used with the disk is found, then the disk binds itself to the file
‫system implementation.
‫So for example, if you attached a disk with a fat header file allocation table header, then we know
‫that the the file allocation table file system should be managing this.
‫So what happens is the kernel isn't aware of this.
‫It will go through every loaded file system and it will call its Resul function and it will say, is
‫this a disk you can manage?
‫And then the file system will read the first sector or whatever it might be for that particular file
‫system.
‫In our case, fact, 16 would read the first header and then it would realize that yes, it is the file
‫allocation table.
‫So in the fact the driver would then say yes to the kernel, we can manage this disk and then that's
‫when the binding process happens.
‫So the communication between user programs and the kernel and the file system goes like this.
‫User programs open a file using F open.
‫It asks the kernel to open this file.
‫The kernel will then talk to the correct file system and it knows which file system is the correct one
‫because the drive number binds to the disk and the disk is binded to the files.
‫Let's now talk about open and the communication for Open with the colonel so we can see the use a program
‫called F Open on the Colonel and it passes in drive zero test subject and it wants to open it in remote.
‫So, OK, so we pass that command to the colonel.
‫Now, the colonel passes this path, drive zero test subject to our path, positive that we've already
‫created the path Pausa returns a path route which specifies disc zero and a path path which specifies
‫test.
‫So we now know our path route is just zero.
‫Our path pass this test.
‫So the colonel will access disk zero from the path route and it will then access the file system that's
‫binded to this group which we know to be fat 16 and then it will call fat sixteen's f open function.
‫And this can be accomplished in the C programming language using function pointers.
‫So obviously this is a complicated cause.
‫I assume you are already aware of that.
‫So if you're not paused the video and learn about function pointers before continuing.
‫So that's how the f open communication works.
‫The fat 16 f open function will then return some private data about itself, which helps define the
‫descriptor that it created with its internal f open function.
‫It returns this private data and when when it returns this private data, the colonel VFW's implementation
‫takes this private data and it creates a file descriptor, OK?
‫And it assigns that private data to this file descriptor.
‫We then return the descriptor back to the user lan so that it can call things like F read F right back
‫to the user program.
‫We now have file descriptor one.
‫We can pass this around to every def.
‫Right, as I just explained.
‫OK, so let's now look at an F read example.
‫So they use a program called Elfriede but is provided this is the local Bufferin, the user program
‫we want to read the data into and we want to read 10 bytes and we pass in the files descriptor that
‫we made in the F open example on the last slide.
‫So we pass this script to the kernel and we call The Ifrit, as I just said, and this is the process.
‫So the kernel looks into our file descriptor.
‫It knows the file system associated with that file descriptor because during the F open process, when
‫it assigned the private data, it also assign which file system I belong to.
‫So we access the file system from that file descriptor.
‫It turns out to be fat sixteen.
‫Now they share the interface to the kernel.
‫Doesn't even know that is fat.
‫Sixteen by the way, because the interface is shared, the function pointers.
‫Right.
‫So what happens is it calls fat sixteen's f read function and it passes in these parameters here.
‫So Elfriede now loads ten bytes into the buffer that we provided from the user land, and that is how
‫the F read works.
‫So let's now go over a quick overview, the virtual filesystem layer allows an infinite amount of filesystems.
‫All the filesystem functionality uses the same interface.
‫The color of file routine's does not have to care about which file system to use.
‫Without the VFW's layer, we would be restricted to simply one file system in our entire kernel, or
‫we'd have a complete mess with a bunch of if statements, switches and who knows what else.
‫It's messy and the virtual file system layer solves that problem.