OSDev.org

Hi,

I need some help with some questions about how I
want my os to work. I am creating my os purely in assembler using nasm as my assembler. Here are the questions I have:

1. What part of the OS contains the filesystems. How would I call them or determine if I have a certain filesystem in assembly.

2. How would I mount/unmount the filesystem in assembly like linux does when it boots up.

3. Should I use paging for my os or use segmented memory modules.

4. which is better: a microkernel or a monolithic kernel
for an os.

beyondsociety wrote: 1. What part of the OS contains the filesystems. How would I call them or determine if I have a certain filesystem in assembly.

There are a number of ways to answer that question; which you should use is a design question you'll have to decide on yourself, and will in part depend on the means by which you call system services both from applications and fro the kernel itself. If you ever intend to support more than one FS, though, you will probably want separate the FS implementation from the service calls to access it, so that the same service calls can be used for different filesystems. Unix uses streams to abstract the file system (and I/o in general) for example; and even the more direct block I/O routines (read() et. al.) are independent of the actual FS used. Conversely, you want to separate the FS from the low-level disk drivers, obviously. Again, how this would work would depend on the driver API.

beyondsociety wrote: 2. How would I mount/unmount the filesystem in assembly like linux does when it boots up.

Well... when Linux boots up, it uses a certain amount of sleight-of-code to read the vmlinuz image file before the full filesystem is loaded, starting with determining what the file system type is. That's part of why a file system has to have kernel support, even when the FS itself is loadable.

As for mounting file systems, what that primarily means is a) identifying the drive and it's type, b) setting up the data structure representing it in core, as well as any loadable drivers need to support it, and c) establishing a mount point (a sort of link) for it to appear at in the root filesystem. In practice, the first two are often done ahead of time for non-removable disks, but with removable medai it must be done every time a new disk (or tape, or whatever) is inserted and mounted.

beyondsociety wrote: 3. Should I use paging for my os or use segmented memory modules.

Again, that's design decision you need to consider yourself, but paging would be substantially easier IIUC. Neither would be very easy to do in pure assembly, however.

beyondsociety wrote: 4. which is better: a microkernel or a monolithic kernel
for an os.

Let's save that flame war for another time...

1. What part of the OS contains the filesystems. How would I call them or determine if I have a certain filesystem in assembly.
---> File systems are usually implemented in the lower layers of an OS. These layers are responsible for accessing the hardware. Considering an examle of linux its upto the VFS(virtual file system) to determine what filesystem is present say on a floppy and then load the appropriate module that provides interface to that file system. All different FS have standards file info tables(FAT,Superblocks), one way is to load these file tables and determine what file system is present

2. Should I use paging for my os or use segmented memory modules.
--->It is upto an OS developer what types of programs he would run on his OS.

Use Paging & segmentation If
a) You require segment size bigger than 1M(2^20)
b) You can oversee internal fragmentation caused due to paging like allocating a single data structure like semops a full page(One can get aroud this problem by grouping many such DataStructure a single page).

Use only Segmentation if
a) You are well off with the 1M max segment size of all segements.
b) You are concerned about the complexity that paging increases in your code.
note: advantages of paging by far overcomes its disadvantages

4. which is better: a microkernel or a monolithic kernel
for an os.
--> its a highly debatable question and one that can spark a war among OS developers. ;D

a)Code Understadability:- Micro is much better than mono as the divides the OS into many parts(like Object Managers in NT. All these objects communicate with each other via a standard messge passing interface).
Each such part can be indivually studied at ease.

b)Code Maintanence:- Micro fares better as indepent parts can be modified without causing problems. like in NT all object have a standard interface, you are not concerned what objects do and how they do it.
Even linux developers were concerned in the starting about this as linux is a mono. It is only due to a large developer base its not a problem now.

c) Speed(i think the most imp criteria):-Monos provide raw speed that micros cannot just working on a simple rule that a single compiled of an OS is much fater than a barebone kernel loading appropriate modules only when required.
Due to juggernautic sizes recent kernels have achieved micros are in vogue.

anubis wrote: 1c) Speed(i think the most imp criteria):-Monos provide raw speed that micros cannot just working on a simple rule that a single compiled of an OS is much fater than a barebone kernel loading appropriate modules only when required.
Due to juggernautic sizes recent kernels have achieved micros are in vogue.

I have a paper on Microkernels by Ulfar Erlingsson that briefly reviews the speed issues related to micros and describes the steps taken in L4 (Liedtke) to better the performance. I'm sure there are more complete reviews, but it may be that the relative microkernel speed issues are true of earlier generations only.

anubis wrote:Use only Segmentation if
a) You are well off with the 1M max segment size of all segements.

Each segment can span up to 4GB, if you set the B bit (which changes the units of the segment limit from bytes to pages). Given that there is no way to turn off paging, how else do you think you can span the 4GB address space?

Tim Robinson wrote: Given that there is no way to turn off paging,

Did you mean "segmentation"??

crazybuddha wrote: I have a paper on Microkernels by Ulfar Erlingsson that briefly reviews the speed issues related to micros and describes the steps taken in L4 (Liedtke) to better the performance. I'm sure there are more complete reviews, but it may be that the relative microkernel speed issues are true of earlier generations only.

hi,
i would be interested to look at it. If its in an electonic version can you mail it to me at [email protected].
I would be thankful as its study could become a part of my term project.

crazybuddha wrote:Did you mean "segmentation"??

Oops, you're quite right; I meant "segmentation". Turning off paging is, of course, a simple matter of jumping to an identity-mapped page, clearing CR0.PG and flushing the prefetch queue.

Tim Robinson wrote: Each segment can span up to 4GB, if you set the B bit (which changes the units of the segment limit from bytes to pages). Given that there is no way to turn off paging, how else do you think you can span the 4GB address space?

Sorry for the guffaw. I forgot about the B bit.

anubis wrote:

crazybuddha wrote: I have a paper on Microkernels by Ulfar Erlingsson that briefly reviews the speed issues related to micros and describes the steps taken in L4 (Liedtke) to better the performance. I'm sure there are more complete reviews, but it may be that the relative microkernel speed issues are true of earlier generations only.

hi,
i would be interested to look at it. If its in an electonic version can you mail it to me at [email protected].
I would be thankful as its study could become a part of my term project.

http://www.cs.cornell.edu/Info/People/u ... ernel.html

It's a pretty breezy read, but makes a nice intro to L4. The exokernel info is basically a summary from other papers.

Thanks for the help crazybuddha, but I'm going to be designing a second generation microkernel and not a first generation or exokernel. Though the help on Interprocess communication was helpful.