now I implementing my FS and VFS, therefore I collect information about them, to make my implementation very clear and efficient.
what minimum interface should VFS have to interact with user process and FS? and the same for FS, surely only with VFS?
for examble, is opendir, readdir ..., a FS functions or VFS or Libc functions.
VFS ?
-
_mark
Re:VFS ?
Here is an example I came across for a simple linux installable fs:
http://lwn.net/Articles/13325/
I would recomend you study the simple example, then look at the actual linux VFS layer.
Basically though, a user process will not directly interact with the VFS layer. This will all be in the kernel hidden behind the standard file routines in libc:
open(), close(), read(), write() etc...
or equivelent such at windows CreateFile(), ReadFile() etc...
The VFS layer really only exposes similar functions as above to the OS. This of course depends on you OS and VFS layer designs. But to make it simple start with just the above.
To the File System however (or the File System developer). The VFS layer will need to provide a very very robust interface to support as many file systems as possible.
This includes ALL directory operations, ALL file operations, and also a fairly robust data structure that can tell all these routines what they are operating on.
Hope this helps
_mark()
http://lwn.net/Articles/13325/
I would recomend you study the simple example, then look at the actual linux VFS layer.
Basically though, a user process will not directly interact with the VFS layer. This will all be in the kernel hidden behind the standard file routines in libc:
open(), close(), read(), write() etc...
or equivelent such at windows CreateFile(), ReadFile() etc...
The VFS layer really only exposes similar functions as above to the OS. This of course depends on you OS and VFS layer designs. But to make it simple start with just the above.
To the File System however (or the File System developer). The VFS layer will need to provide a very very robust interface to support as many file systems as possible.
This includes ALL directory operations, ALL file operations, and also a fairly robust data structure that can tell all these routines what they are operating on.
Hope this helps
_mark()
-
amirsadig
Re:VFS ?
My VFS Data structures include inode, file, super block structure.
when I open a file the VFS should do :
1- check if the inode is readed, if not then read it (inode operation).
2- allocate file describtor and pass the inode and file descriptor to open() function of the correct FS.
my question is, where I should map memory for the opend file? should i map it to inode object or into file object?
what I know for every file there should only one inode object in the kernel memory, but every process could have a file object for that inode but every process had it own linear address. here I come to conflict, how I should map the same file to a diffent linear address, when all process use the same inode object?where I should I save VM region for that file?
when I open a file the VFS should do :
1- check if the inode is readed, if not then read it (inode operation).
2- allocate file describtor and pass the inode and file descriptor to open() function of the correct FS.
my question is, where I should map memory for the opend file? should i map it to inode object or into file object?
what I know for every file there should only one inode object in the kernel memory, but every process could have a file object for that inode but every process had it own linear address. here I come to conflict, how I should map the same file to a diffent linear address, when all process use the same inode object?where I should I save VM region for that file?
-
Tim
Re:VFS ?
The VFS shouldn't do any reading or writing. Ideally, it shouldn't know about inodes or superblocks, because only Unix-type file systems have those. For example, if you built knowledge of inodes into the VFS, you would find it very hard to use FAT or CDFS.
You can use the concept of file handles to solve the multiple process problem. Every time a process opens a file, you check if it's already opened elsewhere. If not, you open it, and allocate a structure containing whatever information you'll need to use that file. Then add another element to the process's handle table, put the pointer to the structure into that element, and return the index of the element to the calling process as a handle. Later, you can look up the handle in the process's handle table and obtain the same pointer again.
You can use the concept of file handles to solve the multiple process problem. Every time a process opens a file, you check if it's already opened elsewhere. If not, you open it, and allocate a structure containing whatever information you'll need to use that file. Then add another element to the process's handle table, put the pointer to the structure into that element, and return the index of the element to the calling process as a handle. Later, you can look up the handle in the process's handle table and obtain the same pointer again.
-
amirsadig
Re:VFS ?
what did you mean?Ideally, it shouldn't know about inodes or superblocks
VFS does not fill the inode with information, this the job of prober FS functions, which each inode has a pointer to them - like open, read, write etc -. as I said before when a process call sys_open() VFS will call the open function of FS related to inode!
how could then VFS found the correct FS to handle a file operations when I use a Tree Directory begin with "/", like unix?
it must be there an interface between VFS and all FS supported with the kernel. here I use inode and FS like FAT must convert its internel data to inode.
have you better idea for VFS ?
-
Tim
Re:VFS ?
You said:
Of course, if you define an FS operation such as 'look up the inode associated with the file at this path' then it would work.
Additionally, I suggest that you use a term other than inode to refer to an 'object describing a file or directory on disk', merely to avoid confusion. BeOS uses vnode. I use file.
I took that to mean that the VFS would know how to read inode structures from disk, and I pointed out that the assumption that every file has a unique inode, and that you can read it from disk, fails for a lot of file systems.check if the inode is readed, if not then read it
Of course, if you define an FS operation such as 'look up the inode associated with the file at this path' then it would work.
Additionally, I suggest that you use a term other than inode to refer to an 'object describing a file or directory on disk', merely to avoid confusion. BeOS uses vnode. I use file.