vfs - mounting

[pradeep]

A good abstraction between drivers and the applications is necessary . So i want to create a vfs ??? what kind of structures do you use? Everything about the vfs is theoretical as far as i saw. But i need answer something more implementation oriented. What kind of information do you store? What is really means mounting? Mounting a partition means you store some information about the partition. Is it right.Then what kind of information do i need to store. If i have to mount a file system under some directory then it means i have to store information about the directory at first. Will you store information about the directory to how many levels? or will you store information about all the directories. If you are going to store information about the directories in vfs do you store their physical CHS location too. What are the type of information needed to be cached for every filesystem. Because i can't once again read from the boot block.
Are my questions relevant to the topic?

[Candy]

A good absraction between drivers and the applications is necessary.

The part in between is commonly called a kernel with libraries.

So i want to create a vfs ??? what kind of structures do you use?

Figure out what a VFS does, figure out how it should work, then write code to do that. Software design 101. Now let's practice what we've learned.

If you are going to store information about the directories in vfs do you store their physical CHS location too.

No, we don't hack your harddisk bios to figure out what the physical CHS values are, we just talk LBA with the harddisk and it translates it for us.

Are my questions relevant to the topic?

...



A VFS is only a VIRTUAL --- FILE SYSTEM. It pretends like all file systems below are one and allows the user to access all of them similarly. It has nothing to do with the rest of the drivers, etc. Except if you are about reimplementing unix, but for that goal enough books are written. I think if you ask AST nice enough he might even write a book "How to write your own Unix clone". Wouldn't help technology move ahead by as much as a single bit however.

[pradeep]

It's becoming more clearer now then before. What will we do on mount call? Say if i want to open a file. What a vfs will do is just forward the request to the appropriate driver.
request
userapp - > vfs -> fat driver -> hdd
reply
hdd -> fat driver -> vfs -> user app
how is the vfs suppose to find the correct driver?
we sure need to store the information about how and where the file systems are mounted. How do we track files?

Consider this:
\ - hdb0,ext2fs
\usr\home - hdb1,vfatfs
\floppy - fd0,fat12

Where such informations are stored?
As for now, just want to open some files read and write.Becoz i have written a floppy disk driver and a hard disk driver i have to sistinguish between fat12 and fat32. At first i want to mount file system at appropriate positions. How to do it?

@candy: you could probably give some pointers to vfs. The materials found in google are based on linux (mostly)

[Warrior]

Easy, check which FS is mounted on which folder. If there is none then use the "Default" or "root" filesystem.

[pradeep]

Ok i give up. Nelson you seem to explain vfs in quite recent posts but all in vain. Could anyone show me how to mount a file system. What is meant by mounting? I like to have a more detailed explanation on this because i am a slow learner.

[Warrior]

It's as simple as reading the block device you want and storing it as (maybe a file) or in a buffer in the selected directory (/mnt/cdrom/ for example) then taking that file and parsing it as if it were the Filesystem.

Although I'm not sure if it would be better to read the block device, parse the FS and store the FORMATTED data as a file or maybe CREATE a directory on the rootFS with a bunch of virtual folders/files pointing to files on the actual disk.

[proxy]

pradeep, VFS really is a simple idea conceptually, but implementations vary which is why you are not getting hard and fast answers. Anyway, here's ONE way to do it.l

you could have a stack with your mountpoints, the stack contains pairs of paths and filesystem objects. filesystem objects will all have the same interface but differeing implementation, and will be assosiated with a specific device/partition. To "mount" a filesystem to / you would push ["/", hd0_3] onto the stack or something like that. in fact if you are doing a unix like dir structure, this should be what the initial mount does so you have _a_ filesystem. likewise if you want to mount some filesystem to /mnt/floppy you would push ["/mnt/floppy", fd0] onto your stack.

Now whenever a user does a file operation you would walk the stack from the top down, stopping on the first which is a complete match on the rightmost part of the path, if you make it to the bottom, remove the last dir from the path and repeat, you will always stop with "/" since it is at the bottom of your stack.

for example:

suppose you have the following mounts (stack in order as shown /home/ is most recent push):

Code: Select all

"/home/", hda0_4
"/", hda0_3

and the user asks for the file "/home/proxy/super/monkey/ball/pics.png"

you would first strip the file name (skip this if last entry of path is a dir) and make sure it ends with a "/" if it doesn't.

compare "/home/proxy/super/monkey/ball/" to the contents of your stack, no hit,
then compare "/home/proxy/super/monkey/", no hit,
then compare "/home/proxy/super/", no hit
then compare "/home/proxy/", no hit
then compare "/home/", hit!

ok, so now we know that this file resides on the mounted filesystem associated with "/home" which we can simply look up in our stack and see that it is hda0_4, yay.

finally, we direct our request to the hda0_4 object, done.

this is one of many ways to implement a VFS layer in a unix like way, it is strictly off the top of my head so don't take it as gospel, but if done correctly, it would work.

in linux the function which does a lot of this work is "user_walk_path", you may want to look at that for an example.

proxy

[Pype.Clicker]

the thing to understand VFS behaviour is to stick in our mind that what's now associated with a 'mount point' is no longer a disk driver but rather a filesystem instance. E.g. in pre-VFS days, we'd have something like

Code: Select all

interface DiskDriver {
   init(); reset();
   readblock(block_id, buffer); 
   writeblock(block_id, buffer);
}

class MountPoint {
    DiskDriver driver;
    String path;
}

open(filename) {
   String sub_path;
   mountpoint=scan_mount_tab(filename,&sub_path);
   while (sub_path.notSimple()) {
       mountpoint.driver.readblocks(<directory>);
       scan_for_direntry(sub_path.first_item())
   }
}

(well more or less). With VFS, what you get is an instance of VfsDriver which instead offers

Code: Select all

interface VfsDriver {
    VfsNode open(path);
    VfsNode create(path);
    status delete(path);
}

interface VfsNode {
    read_blocks(file_offset, bufer);
    write_blocks(file_offset, buffer);
    append_blocks(file_offset, buffer);
}

and other things alike (BeFS document gives very good insight at what's needed there).

Fat12, Fat32, ReiserFs etc. will all be implementations of VfsDriver, and each will return Fat12Node, Fat32Node, ReiserNode which are in turn implementations of VfsNode.

That means your kernel only deals with 'virtual items' the very same way regardless of what driver actually handles them (very basic principles of OOP)

[Exabyte256]

*Tries to come up with a VFS*

Have records that link to eachother as normal, then keep track of which filesystem ID they belong to (this can be done manually or inherited from parent).

When the user changes directory, read that directory with the filesystem driver depending on the ID. Perhaps keep track of whether you've read the directory already to keep down processing. Then mounting just involves creating a new directory and setting it to a device, partition or file.

Code: Select all

Record [] ReadNTFS(deviceOrPartition, string directoryName)

OnChangeDirectory()
{
  if(Updated == True) return
  switch(Type)
  {
    case NTFS:
       FillVirtualDirectory(Device, DirectoryName,ReadNTFS(DirectoryName))
       break;
  }
  Updated = True
}

Mount (Device = HD0, Type = NativeFileSystem, Updated = True)
Record1 Windows

Windows (Device = HD1, Type = NTFS, Updated = True)
Record1 Documents and Settings
Record2 Program Files
Record3 Windows
Record4 boot.ini
Record5 ntdetect.com
...

Documents and Settings (Device = HD1, Type = NTFS, Updated = False)
Record1 Default User
...

Hrm... quite good, quite good. I'll use this idea for my own OS, unless anyone sees any problems with it?

[proxy]

well your idea works fine for chanign dirs, but what about opening files which are not in the current dir, you will still need to walk the path to find out which filesystem/mountpoint the file resides on.

proxy

[pradeep]

@ proxy: you made it clear. This is what i am looking for?
@ Pype: pre VFS and VFS made me more clearer. But on seeing some linux related documents about vfs, i like to know the necessary fields of a file system instance.
@ (n)asm programmers: Have anybody of you felt little sad for having chosed to write kernel in asm. Have anybody succeeded with vfs? Because i am feeling little difficult with vfs since i have to use a lot of structures and vtables. Nasm supports struct's too but the syntax is horrible. What is the better way to deal with a lot of structures?

[Pype.Clicker]

i once used nasm a lot and that conducted me to write _many_ macros, including some to write structure-supporting code such as

Code: Select all

with <register>,<structure>
load <field>,<target>  ;; equivalent to mov target,[register+structure.field]
store <field>,<source> ;; equivalent to mov [register+structure.field],source.

that made nasm+ code easier to write but more complex to read for third-party (even if there never was third-party at that time ^_^)

[pradeep]

Won't the recursive calling of macros affect the program sequence. I have to deal with structure to structure and sometimes with structure -> structure ->structure. With this complexity will be added by array and multidimensional arrays. Will the macros be more reliable.
In case of multidimensional arrays of structure what will you do?

Code: Select all

structure1 [10] [5] ;
structure1 [eax*structure2[5]][5];

then how will you construct the macros? It's becoming more tidy. Should i use macros for arrays too?
It seems complex for myself to read.
But it will be more complex to read without the macros. >:(
If some one is going to read it without macros how would it be?

[pradeep]

Though the basics are clear now still some doubts are to be cleared before making my hands dirty.
The device driver passes a device_t structure to the vfs and the vfs is responsible for adding the devices. If it is a FSDriver then it passes a virt_device_t structure. The devices are added and the vfs is responsible for calling the FSdriver's mount function.
But from Mobius Documents the buses are responsible to detect those devices. If so then how the sequence goes?

If we are passing a virtual function table that means the functions are static, that is if more functions are to be added to the drivers it's not possible without modification to the kernel. So would it be better just to pass the message to the driver.

[Candy]

Please don't start a new topic on the same subject.