I'm announcing my OS project.

Yes, that's right. Finally, I’ve considered opting for a project that I can meticulously research, design and implement an operating system. I’ve wasted too much time conceptualizing on the perfect, ultimate and efficient operating system, when I don’t even have the level of feasibility to develop the basics, as compared to a full intricate system. In this project, I aim to research, to learn, to simply, to build and to document. I also plan to keep a principle of professionalism.

Now, enough of the verbose talking. Let's get to the facts. This is my project thread. I'll be discussing the project here (for help, so thanks in advance).


GOALS

Here are my goals:
- Run concurrent applications
- Multi-stage bootloader ?
- File system support [VFS]
- Multitasking
- Paging memory management
- Process management
- Command-line shell (using it's own fonts and primitive screen functions)
- (Potentially a very minimalistic and simplistic GUI to demonstrate the concept)
- Speed? No. I wish not to worry about speed and security at this moment, since I'm still learning.
- Research and learn about general-purpose OS'

EDIT:
Places to find the project:
- www.vedia.zxq.net - Project homepage
- www.vedia.clanteam.com - ^ Mirror site (using iframe)
- www.vedia.googlecode.com - Project page
- www.projectvedia.tumblr.com - DevBlog

Old threads:
- OS Development?
- Help: An attempt at OS dev, again

Good luck! If I can provide anything constructive I will.

Thanks smiddy! I'll need it.

FAT12 ?
Binding the OS to one particular file system promises problems later, when you decide to implement another one.
IMHO, the file system is matter of driver.
But if you want to hard-code the file system, better choose FAT32.

better to do an internal layer about file systems too. and use others files systems with just drivers to this layer. then, only one code is needed to use any supported file system.

JohnFound wrote:

FAT12 ? Binding the OS to one particular file system promises problems later, when you decide to implement another one. IMHO, the file system is matter of driver. But if you want to hard-code the file system, better choose FAT32.

edfed wrote:

better to do an internal layer about file systems too. and use others files systems with just drivers to this layer. then, only one code is needed to use any supported file system.

To these points I agree, unless you have a reason for going down the FAT12 path (only using floppy for development, for example), you can make excellent progress if you can set it up to implement many file systems, perhaps developing your own, which doesn't limit other who can help you such that they have a compatible environment to load/play/test it for you.

I don't want to hard-code it. What't the benefit of different file systems?

There's no reason for FAT12. I just thought that it might be easier, though its limited. Since supporting multiple file systems can be done using drivers.

Can how explain how this might be done?

This means a virtual file system. The vfs would have would have code that knows the different file systems (fat12, fat32, ntfs), so that would mean a possibility of supporting floppy drives, cd drives and hard drives. correct?

adroit wrote:

This means a virtual file system. The vfs would have would have code that knows the different file systems (fat12, fat32, ntfs), so that would mean a possibility of supporting floppy drives, cd drives and hard drives. correct?

more or less... but you would have to have a driver for each of those devices that the file systems' drivers can use to get a file

adroit wrote:

This means a virtual file system. The vfs would have would have code that knows the different file systems (fat12, fat32, ntfs), so that would mean a possibility of supporting floppy drives, cd drives and hard drives. correct?

The goal of a VFS is to be both filesystem independent and hardware independent. It's a layer that sits in between and allows the kernel to connect hardware support drivers (magnetic, optical, flash, ... but also network-based) to every single type of filesystem available, and potentially even non-filesystem structures such as compressed archives, disk images, etc.

Understood. Sounds complex.

So the VFS will site between the actual file systems and system calls as an interface.

adroit wrote:

Understood. Sounds complex. So the VFS will site between the actual file systems and system calls as an interface.

I recall a link somewhere that discusses it more, osdev.org maybe? Anyhow, essentially you are correct, but I think that may be an over simplification. You have to manage the "file system" which can be any software implementation on any hardware implementation. So there is the software part of the file system and the hardware, then there's the interface to your OS, and several other layers of interface eventually to the "user" of the OS. That is basically how I see it. (Your mileage may vary (YMMV))

I found this: http://www.ece.iupui.edu/~dskim/Classes/ECE408/ln-os-ch11%20File-System%20Implementation.pdf

If I were you, I would define at first the driver interface API - the procedures every file system driver have to provide. It is good this API to be as small and simple as possible.
For example - procedures for finding files by its names, directories scan (in order to build directory lists), file attributes, user permissions and so on. Some simple basic file read/write procedures - for example read/write of whole clusters from/to given file.
Then the OS clients only have to call these procedures for the respective FS without any need to know what driver will provide the result. The advanced read/write functions can be implemented on top of the driver functionality and to be FS independent.

smiddy wrote:

but I think that may be an over simplification.

"[My] mileage may vary" you're probably right. Thanks for the link.

Ahhh nice. Apparently there's a vast amount of stuff to learn! JohnFound, as I get a little deeper I'll try to attempt this. Because...

I just got a copy of the os design and implementation book. i remember bitshifter telling me to look at the minix source, study it (like linus did). i'll come across those techniques later. Yay! Though minix is in C and I wanted to do this OS in asm.