OSDev.org

Now I face the problem: how do I keep track on the opened files and dirs. I imagine my vfs layer like this:

vfs: check path and select fs module
fs mod: do the stuff

Now I'm sure there is somewhere a list of all open files, so we can check if they were opened.. how do you all manage this?

Cheers,
Adrian

With a list .

Literally, link all the open files together in a list. Or for greater efficiency, some more appropriate data structure such as a hash table.

Thank you, well the simplest solutions are the ingenious ;D

Off to coding then, I'll see how does it work in practice.. what should I do if one file has been opened multiple times? I suppose there is a list for open files, and each entry describes the file opened and gives a list of all processes which open it yes? And, what should I include in either lists' entries?

Ok, I'll start with open()

[design]
-vfs layer: contact the module which mounts the volume
-check if file exists
-check (from the first list!) if the file is already open and if yes, do we allow another process to open it in the mode requested (r, rw etc. what modes are there?)
-if sucess, create or update entry in first list(is there some special name for it?)
-create the other list's entry for this process (the entry format is in standardised format, or does each module save the data in it's way?)
-return success
[/design]

That does not seem so complicated as I thought.. when reading a dir, open_dir() works like open() yes? and the difference between dirs/non-dirs is that readdir() is allowable?

Cheers,
Adrian

to handle , multiple opens, i would probably have a reference count associated with each structure. on initial open, set to 1, each subsequent open increment. on each close decrement, if it goes to 0, remove the node from the list.

proxy

I have two levels of indirection relating to open files: file handles and files.

A file_handle_t is what an application gets when it calls FsOpen. It contains the read/write access flags and a pointer to the underlying file. A new file handle is created for every call. File handles can be shared between processes.

There is one file_t object or each file the kernel knows about. Re-opening a file (e.g. two applications both opening the same file name, or opening two files linked to the same inode) increments the reference count on the file object. file_t contains all the data structures the kernel needs, including the file's cache, a pointer to the file system driver, and a unique cookie provided by the FSD that refers to the file. An FSD cookie is usually the inode number of the file on the disk, but can be more complex for file systems that don't have inodes (e.g. FAT).

All the file_t's are chained together, and hashed. So FsOpen looks something like this:

Thank you for your replies!

The file's cache is kernel-wide? Would it be a bad idea to make it private for the fs-module?

And the floppy driver: how do you keep cache for it? Is it wise to alloc 1,44 Mb lazy-paged into one buffer then just have a stack of blocks availlable in the cache?

Cheers,
Adrian

Adek336 wrote:The file's cache is kernel-wide? Would it be a bad idea to make it private for the fs-module?

It's up to you. The FS and virtual memory manager tend to be quite tightly coupled. The FS relies on the memory manager for cache memory, and the memory manager relies on the FS for memory mapped file support. If you're clever you can implement memory mapped files by mapping user mode memory directly into the FS's cache.

And the floppy driver: how do you keep cache for it? Is it wise to alloc 1,44 Mb lazy-paged into one buffer then just have a stack of blocks availlable in the cache?

I don't do block device caching at all -- it's all done at the file level. Doing it that way lets you use tricks like I just mentioned. It also makes maintaining coherency between memory mapped files and cached file I/O easier (you can implement cached file I/O as memcpy to and from the cache).

Note that BeOS never supported mmap properly for this reason.

Hmmm ...

BlueIllusion is at a stage, where some biig misconceptions come into play: the block chache is merely a linked list of sorts: I store blocks in an area of an element, and the element is hooked into the list of cached blocks. Kinda crap this is. I didn't think enough about it.

Now, there comes an Idea (inspired by Pype san): What about assigning an extra area to the adress space of the file service, which the pager accesses to map blocks - and the chain for each inode which is brought into memory is assigned such an area. the blocks are stored there and only pointers to the start of a block are saved in *block_t*. the pager keeps a list of assigned areas (with owner, node_number and some kind of tree, in which the physical adresses of the assigned pages are stored, who accesses them... (for quick access - it is yet to grow in my head - so take it with a grain of salt)

A process can now either access the file via read/write or via mmap/mumap - which fetch the according pages and enter them in its adress space, roughly spoken.

Well, it's kinda funny to do this stuff in a micro kernel *gg*.

Yahoo I got my file_t/file_handle_t lists running ;D Now, I was thinking about My scheme is as follows:
-create a file_handle_t for this file
-tell the appropriate module to check the file

Now: Will contact the fat12/fdc module (coz' it's mounted at /mnt/fd0). The fat12 module gets thrown a file handle, allocated by vfs_open(). As we know, so the fat12 mod must know the place it has been mounted to, yes?

Cheers,
Adrian

PS why do we need loop devices to read floppies like files?

PS why do we need loop devices to read floppies like files?

Well, actually, the loop device is more generally used to read a file as if it was a floppy (which should be a device).