flat assembler
Message board for the users of flat assembler.

Index > OS Construction > Project Vedia

Author
Thread Post new topic Reply to topic
adroit



Joined: 21 Feb 2010
Posts: 252
adroit 12 Feb 2012, 18:21
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

_________________
meshnix


Last edited by adroit on 23 Feb 2012, 01:26; edited 2 times in total
Post 12 Feb 2012, 18:21
View user's profile Send private message Reply with quote
smiddy



Joined: 31 Oct 2004
Posts: 557
smiddy 14 Feb 2012, 17:19
Good luck! If I can provide anything constructive I will.
Post 14 Feb 2012, 17:19
View user's profile Send private message Reply with quote
adroit



Joined: 21 Feb 2010
Posts: 252
adroit 14 Feb 2012, 18:23
Thanks smiddy! I'll need it. Smile
Post 14 Feb 2012, 18:23
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3499
Location: Bulgaria
JohnFound 15 Feb 2012, 07:23
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.
Post 15 Feb 2012, 07:23
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4347
Location: Now
edfed 15 Feb 2012, 09:21
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. Smile
Post 15 Feb 2012, 09:21
View user's profile Send private message Visit poster's website Reply with quote
smiddy



Joined: 31 Oct 2004
Posts: 557
smiddy 15 Feb 2012, 17:33
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. Smile


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.
Post 15 Feb 2012, 17:33
View user's profile Send private message Reply with quote
adroit



Joined: 21 Feb 2010
Posts: 252
adroit 15 Feb 2012, 22:00
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?
Post 15 Feb 2012, 22:00
View user's profile Send private message Reply with quote
adroit



Joined: 21 Feb 2010
Posts: 252
adroit 16 Feb 2012, 02:12
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?
Post 16 Feb 2012, 02:12
View user's profile Send private message Reply with quote
xleelz



Joined: 12 Mar 2011
Posts: 86
Location: In Google Code Server... waiting for someone to download me
xleelz 16 Feb 2012, 02:30
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

_________________
The person you don't know is the person that could help you the most... or rape you, whichever they prefer.
Post 16 Feb 2012, 02:30
View user's profile Send private message Reply with quote
ManOfSteel



Joined: 02 Feb 2005
Posts: 1154
ManOfSteel 16 Feb 2012, 07:16
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.
Post 16 Feb 2012, 07:16
View user's profile Send private message Reply with quote
adroit



Joined: 21 Feb 2010
Posts: 252
adroit 18 Feb 2012, 12:50
Understood. Sounds complex.

So the VFS will site between the actual file systems and system calls as an interface.
Post 18 Feb 2012, 12:50
View user's profile Send private message Reply with quote
smiddy



Joined: 31 Oct 2004
Posts: 557
smiddy 18 Feb 2012, 12:58
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))
Post 18 Feb 2012, 12:58
View user's profile Send private message Reply with quote
smiddy



Joined: 31 Oct 2004
Posts: 557
smiddy 18 Feb 2012, 13:01
Post 18 Feb 2012, 13:01
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3499
Location: Bulgaria
JohnFound 18 Feb 2012, 13:06
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.
Post 18 Feb 2012, 13:06
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
adroit



Joined: 21 Feb 2010
Posts: 252
adroit 23 Feb 2012, 00:40
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! Very Happy 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.
Post 23 Feb 2012, 00:40
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.