8 replies to this topic

[mebob]

I mean in Linux, if you were programming in assembly, you would use int 80 to output text to the console. How does Linux identify what process is interrupting?

[RhetoricalRuvim]

At a guess, it would either track which process/thread is currently being executed by the current processor, or it could probably use the interrupt return far address pointer and check to which process's address space the address points.

On the operating system I'm planning to write (some day; ...), the latter is not really an option, because I want the currently-executing process to be loaded into a specific application address space, and unloaded before loading the next process in the to-be-executed thread list; I think that is a better way to manage memory. That way is not the fastest method, but it's not the slowest either.

[mebob]

Thanks, at the moment I was having trouble thinking about the full picture. I wasn't considering that at every context switch the kernel would be keeping track of what was currently running. Then, if it knew what was running, it should be pretty obvious how it knows who's calling :D One of those slow moments. I actually was considering the idea of it using the return address from the interrupt. It would make sense if you were multitasking using segmentation with the GDT however it wouldn't quite work when using paging (or at least I don't think it would).

About your description of how the OS you will write in the future will manage memory: I don't quite understand. Could you re-explain?

PS: I too plan on writing an OS sometime as well.

[RhetoricalRuvim]

What's with all these programmers wanting to write their own operating systems? :) No, I'm just kidding, it's okay.

My idea is somewhat like this:

memory: 


apps: 

app1 { code, data } mems: mem1, mem7, ... 

app2 { code, data } mems: mem4, ... 

app3 { code, data } mems: mem7 

... 

appn { code, data } mems: mem7, mem8, ... , memn 


mems: 

mem1 [ ... ] 

mem2 [ ... ] 

mem3 [ ... ] 

... 

memn [ ... ] 


... more stuff in memory ... 


process execution environment address space: 


// Every time another thread is to be executed, this thread's data section and allocated memory pages 

// are loaded back to the above app data space and the necessary allocated memory page blocks, respectively. 

// When that's done, the new thread's process (app) is loaded here to its proper location in the 

// execution environment's address space. Each process's allocated memory is loaded here, as well. 


// This way we can have everything an application needs all in one place. 

// Also, this way we can move chunks of memory around in the apps and mems 

// address space without interfering with any of the applications' allocated memory 

// pointers. 


// Here, nothing is static (ie there is no specific border for where the code segment should end; no limit on where to put the (allocated) data pages, etc.). 

// The only exception is that addresses mostly remain constant for each process, throughout its execution. 


code: 

... 


data: 

... 


allocated memory blocks (mems): 

mem#: 

... 

mem#: 

... 

mem#: 

... 

..... 

So that's the idea.

It should help with memory management because that way it is possible to move things around, in memory, without interfering with any of the applications' pointers to memory blocks.

Let's say app1 starts, and allocates a piece of memory, mem1. Then, later, allocates another piece of memory, which the operating system identifies as mem7. It decides to share that piece with some other apps. But since we don't want apps accessing each others' memory addresses, we just have a mem pool, with all the allocated memory blocks stored there, and we can pull the blocks out as needed.

That way each app only has pointers to memory blocks that it is allowed to access, and we can manage the mem pool as we want, without interfering with any of the apps' pointers.

I hope you understand what I mean; it's kind of hard to explain.

[mebob]

With paging you wouldn't have to worry about interfering with the app's pointers, I don't think. Also, the overhead of moving it around would probably diminish any advantages.

[RhetoricalRuvim]

Better than accessing the disk all the time, for virtual memory, I think. I could also probably add in some optimizations, such as on-demand block loading, or maybe paging. Though if I use paging, I'd probably add it in later on, because I first need more of a grip on some of the more basic things, and at least get those working first. I think it would be called "byte more than you can chew" , if I go for too many things at once (this is already plenty to work with).

[mebob]

I wasn't talking about virtual memory on-disk at all.

[RhetoricalRuvim]

Even so, I'd rather stick with what I know, at least for now. After all, it's better to have at least something, than to bite more than one can chew, and then end up not having anything at all.

[AKMafia001]

It's the PCB (Process Control Block). The OS keeps all the data it needs about a process in the PCB.

 pcb.png   32.13K   12 downloads

Process Identification
- Process ID, a unique numeric identifier
- User ID
- Who runs the process. Why?
- Used to determine what access rights the process has

Process Address Space
- A list of memory locations from some min (usually 0) to some max that a process can read and write.
- Contains:
- the executable program
- program’s data
- Stack
- Associated with a process is a set of registers e.g. PC,SP and other information to run the program.

 pcb.png   42.35K   28 downloads

CPU Switch From Process to Process
- Switching a process requires
- Saving the state of old process
- Loading the saved state of the new process
- This is called Context Switch
- Part of OS responsible for switching the processor among the processes is called Dispatcher

 pcb.png   63.69K   27 downloads

The Process have states:
- Running Running currently in the CPU
- Ready Ready to run -- waiting for the CPU to get free
- Blocked Blocked, waiting for an event to occur. When the event occurs it goes to ready state.

New Process is in Ready (not running) state always .

Hope this Helps!