Oh, big troubles are ahead of me.
I am going to build basic - *very* basic - support for the ext2-filesystem into my kernel - how should it be else - in form of a service process.
well, some list manipulating routines, I have already at hand, now, I have to create a process list in the realm of the file service - if a process opens a file, it is registered with the file service, gets a list of file pointers (many file pointers can point to one inode), which will be filled in.
It looks like this one will bring more work than the kernel itself. I'll need some bitmap searching routines for the block bitmap block and the inode allccation block.
For God's sake there are some good ressources in the www. The Linux Source code is not the best to read.
anyway, BlueIllusion wouldn't be useful without any file system support. and where is the witz of an operating system that doesn't offer structured disk access?
stay safe, folks!
File System Support
-
- Member
- Posts: 1600
- Joined: Wed Oct 18, 2006 11:59 am
- Location: Vienna/Austria
- Contact:
File System Support
... the osdever formerly known as beyond infinity ...
BlueillusionOS iso image
BlueillusionOS iso image
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:File System Support
well, one thing that could help you is to build an alternate in-memory representation of the most used bitmaps (like a tree of free zones ...)
When reading the bitmap's block, you build that tree and use it for searching rather than using linear sweep of the bitmap ...
When reading the bitmap's block, you build that tree and use it for searching rather than using linear sweep of the bitmap ...
Re:File System Support
A technique I've been using is to treat file system structures as files. This means I can use the same core kernel cache code to read and write things like the FAT and directories. In the FAT driver, the only difference comes in converting an offset within the 'file' to a sector number. For files and directories, this causes a read from the FAT 'file'; for the FAT itself, it is relative to the start of the FAT on disk.