Virtual File System Functions

[Jeko]

Exactly - it's dealt with via the function pointers I explained above again and again...

At the VFS level there is no such thing as a mountpoint - just the inodes in / and the inodes in /dev would have their read()/write()/etc function pointers pointing at different places, the former to the ext3 read/write/etc functions, the latter to the devfs read/write/etc functions.

but without a list of mountpoints it's impossible...

In your tutorial, you handle the dev mountpoint with the initrd filesystem...

[z180]

i have for every mounted fs an struct vfs that contains some per
fs independent data and a pointer to fs dependent data.
in every inode of my system there is a pointer to the vfs where the
inode belongs to.

[JamesM]

but without a list of mountpoints it's impossible...

No it's not! stop being so tunnel minded and *read* and *understand* what you are being told!

When my devfs tutorial comes out you will understand how everything fits together, hopefully, but I'm a long way off writing that yet!

[zaleschiemilgabriel]

I really don't see what is so hard to understand... Basically you have a tree structure in which each node has a number of sub-nodes. Mount and unmount operations are as simple as adding/removing nodes from the tree. Each node contains a set of function pointers (for syscalls) which might be NULL if the specified operation is not supported on the device. This way, the functions can also be used to create filter device drivers, which simply take the pointer for a function, save it somewhere and replaces it with a pointer to one of it's own functions, which filters/modifies the request/response data and then calls the saved pointer to do normal processing. This is actually quite a good idea.

[Jeko]

I really don't see what is so hard to understand... Basically you have a tree structure in which each node has a number of sub-nodes. Mount and unmount operations are as simple as adding/removing nodes from the tree. Each node contains a set of function pointers (for syscalls) which might be NULL if the specified operation is not supported on the device.

I understood this, I wanted to know how to mount a FS on another FS. Now I understand everything!

[Jeko]

I changed the design of my VFS.

I have a list of mountpoints:
typedef struct mountpoint {
char *device;
char *root;
fsd_t *driver;
} mountpoint_t;

A driver structure for filesystems:
typedef struct fsd {
char *name;
//There are all functions of filesystems
} fsd_t;

And a file handle structure:
typedef struct fs_handle {
mountpoint_t *mount;
char *name;
//Some file informations
};

The function that opens a file is something like this:

Code: Select all

fs_handle_t *open(char *name, int mode)
{
        //Find a mountpoint for the file

        //The new name of the file is name - mount->root
        //For example if the mount->root is '/dev'
        //and the file name is '/dev/hd0'
        //Then the new name is '/hd0'
        return mount->driver->open(name, mode);
}

So I have an handle and I can do file operations with this handle.
I can also do something like an handle cache.

[Jeko]

For the argument, is better to pass to the filesystem driver:
the complete path (for example /dir/dir2/file.txt) or a dir at a time (open dir, if exists dir2 in dir open dir2, if exists file.txt in dir2 open file.txt)

[zaleschiemilgabriel]

If you mean for identifying files, you should offer user applications a way to enumerate devices and files with either fully-qualified or relative paths.
As for internal processing of paths, it's up to you to choose the best way to convert those paths to inodes. I assume you would have a global fopen function for opening files. It would take as parameter a path (either full or relative). The first thing this function should do is locate the inode corresponding to the file path. Once it finds it, the "open" function in the inode is called to create a new file handle (or whatever representation of a file you use). Anyway, there are many places inside a file system driver where you need to deal with either relative or full paths, so your question is a bit ambiguous to me.

[Jeko]

If you mean for identifying files, you should offer user applications a way to enumerate devices and files with either fully-qualified or relative paths.
As for internal processing of paths, it's up to you to choose the best way to convert those paths to inodes. I assume you would have a global fopen function for opening files. It would take as parameter a path (either full or relative). The first thing this function should do is locate the inode corresponding to the file path. Once it finds it, the "open" function in the inode is called to create a new file handle (or whatever representation of a file you use). Anyway, there are many places inside a file system driver where you need to deal with either relative or full paths, so your question is a bit ambiguous to me.

When I open a file with the filesystem driver, I must do like this:

Code: Select all

driver->open("/dir2/dir/file.txt");

or like this:

Code: Select all

inode = driver->open("/dir2");
if in inode there is dir
inode = driver->open("/dir");
if in inode there is file.txt
inode = driver->open("file.txt");

How must I do when I open a file? Getting the inode dir by dir or passing complete path to the driver?

[JamesM]

If you mean for identifying files, you should offer user applications a way to enumerate devices and files with either fully-qualified or relative paths.
As for internal processing of paths, it's up to you to choose the best way to convert those paths to inodes. I assume you would have a global fopen function for opening files. It would take as parameter a path (either full or relative). The first thing this function should do is locate the inode corresponding to the file path. Once it finds it, the "open" function in the inode is called to create a new file handle (or whatever representation of a file you use). Anyway, there are many places inside a file system driver where you need to deal with either relative or full paths, so your question is a bit ambiguous to me.

When I open a file with the filesystem driver, I must do like this:

Code: Select all

driver->open("/dir2/dir/file.txt");

or like this:

Code: Select all

inode = driver->open("/dir2");
if in inode there is dir
inode = driver->open("/dir");
if in inode there is file.txt
inode = driver->open("file.txt");

How must I do when I open a file? Getting the inode dir by dir or passing complete path to the driver?

You must do whatever your interface forces you to do, and you design your interface, so you choose.

Seriously, you've posted topics on pretty much every aspect of your OS's interfaces - you should design them yourself!

[z180]

I do not develop now but i wrote a lookup function which takes
a pathname and finds the file and a seperate open function and a seperate function for creating files only like fifos with "mkfifo" prog.
My VFS is using
an inode representation for each file and a VFS structure but have no file_operations structure that linux and BSD have.Also devices are
not hard coded, but dont use a complex devfs.

[zaleschiemilgabriel]

I'm not much of a Linux person, so I didn't get much of what you said, but go with the full path name if you don't use inodes, then use your lookup function inside your open function to find out if the file exists, then open it once you find it... although I'm not really sure your lookup function does what I think it does. Anyway, handle full paths as an interface to your driver, and offer separate API functions for dealing with relative-paths (to convert them to full paths before passing them to the driver).

[Jeko]

I have some doubts:
Opening a file dir by dir puts in my inode cache all dirs opened, and this is a very waste (or not?)
Opening a file with complete path puts in my inode cache only most used files. I think I will do like this.

However I don't want that you make design decisions for me, I want that you comment my design decisions and tell me (if there are two opportunities) which, in your opinion, is the best.
Thank you!

[AJ]

Hi,

Opening a file dir by dir puts in my inode cache all dirs opened...Opening a file with complete path puts in my inode cache only most used files...

So if you have a character string containing the absolute path (your second option), how is your File System going to find that path? As I see it, you have two options here, too:

1. You must make each file system implement its own GetFile(char*) function. If you get to the stage where third parties are writing modules for your OS, this seems to me to make for lots of redundant code and bulky drivers, but you have no risk of anything getting in to the inode cache that you don't want in there (the driver does its own internal search).

2. You have a single search function provided by your VFS. Each driver only needs to provide something like GetFile(parentdir, index) and your VFS does the recursion. Of course, you can be selective about what does and does not get added to the inode cache.

Personally, I'm going for something closer to option 2. You may have thought of something completely different, of course

Cheers,
Adam

[Jeko]

Hi,

Opening a file dir by dir puts in my inode cache all dirs opened...Opening a file with complete path puts in my inode cache only most used files...

So if you have a character string containing the absolute path (your second option), how is your File System going to find that path? As I see it, you have two options here, too:

1. You must make each file system implement its own GetFile(char*) function. If you get to the stage where third parties are writing modules for your OS, this seems to me to make for lots of redundant code and bulky drivers, but you have no risk of anything getting in to the inode cache that you don't want in there (the driver does its own internal search).

2. You have a single search function provided by your VFS. Each driver only needs to provide something like GetFile(parentdir, index) and your VFS does the recursion. Of course, you can be selective about what does and does not get added to the inode cache.

Personally, I'm going for something closer to option 2. You may have thought of something completely different, of course

Cheers,
Adam

Thanks for your opinion!
Your second option is better, I like it because I want to make module programming more simple as possible. I can choose which inodes won't be cached. It's a good idea.
Thank you!