• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

OS2 & eCS kernel

Started by miturbide, 2007.05.16, 22:38:54

Previous topic - Next topic

demetrioussharpe

Quote from: RobertM on 2011.05.11, 23:14:09
Martin,

Love your idea for it. It is a great starting point. Alas, OS2KRNL replacement will also probably need an OS2LDR replacement. Demetrious has his work cut out for him.

Another interesting thing, IIRC, OS2KRNL is currently part assembly and part C. Not that it's probably very relevant.

I'm also wondering how helpful the new/upcoming AMD BIOS in CPU stuff may be to this effort. Not so much on the Intel side, of course...

I kinda assumed that a new kernel would need a new bootloader & a new userland in order to function. The bootloader can actually be outsourced from other projects. The userland has to be written specifically for the kernel, so I assumed that it was an implied task.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

RobertM

Quote from: demetrioussharpe on 2011.05.11, 23:50:31
Quote from: RobertM on 2011.05.11, 23:14:09
Martin,

Love your idea for it. It is a great starting point. Alas, OS2KRNL replacement will also probably need an OS2LDR replacement. Demetrious has his work cut out for him.

Another interesting thing, IIRC, OS2KRNL is currently part assembly and part C. Not that it's probably very relevant.

I'm also wondering how helpful the new/upcoming AMD BIOS in CPU stuff may be to this effort. Not so much on the Intel side, of course...

I kinda assumed that a new kernel would need a new bootloader & a new userland in order to function. The bootloader can actually be outsourced from other projects. The userland has to be written specifically for the kernel, so I assumed that it was an implied task.

LoL, I knew you already thought of that (or was pretty darn sure you'd already considered all of that). Was clarifying for others who may not have considered such.

Here's something I was just thinking of, due to another thread, but how many hand-offs/reliances (if any) are there in PMMERGE?


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


demetrioussharpe

Quote from: RobertM on 2011.05.11, 23:56:22
Quote from: demetrioussharpe on 2011.05.11, 23:50:31
Quote from: RobertM on 2011.05.11, 23:14:09
Martin,

Love your idea for it. It is a great starting point. Alas, OS2KRNL replacement will also probably need an OS2LDR replacement. Demetrious has his work cut out for him.

Another interesting thing, IIRC, OS2KRNL is currently part assembly and part C. Not that it's probably very relevant.

I'm also wondering how helpful the new/upcoming AMD BIOS in CPU stuff may be to this effort. Not so much on the Intel side, of course...

I kinda assumed that a new kernel would need a new bootloader & a new userland in order to function. The bootloader can actually be outsourced from other projects. The userland has to be written specifically for the kernel, so I assumed that it was an implied task.

LoL, I knew you already thought of that (or was pretty darn sure you'd already considered all of that). Was clarifying for others who may not have considered such.

Here's something I was just thinking of, due to another thread, but how many hand-offs/reliances (if any) are there in PMMERGE?

I'd imagine that the skeleton DLLs that replaced the original DLLs that combined into PMMERGE.DLL all rely on it. But that's going to have to eventually be reimplemented also.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

demetrioussharpe

Quote from: RobertM on 2011.05.11, 23:56:22
Quote from: demetrioussharpe on 2011.05.11, 23:50:31
Quote from: RobertM on 2011.05.11, 23:14:09
Martin,

Love your idea for it. It is a great starting point. Alas, OS2KRNL replacement will also probably need an OS2LDR replacement. Demetrious has his work cut out for him.

Another interesting thing, IIRC, OS2KRNL is currently part assembly and part C. Not that it's probably very relevant.

I'm also wondering how helpful the new/upcoming AMD BIOS in CPU stuff may be to this effort. Not so much on the Intel side, of course...

I kinda assumed that a new kernel would need a new bootloader & a new userland in order to function. The bootloader can actually be outsourced from other projects. The userland has to be written specifically for the kernel, so I assumed that it was an implied task.

LoL, I knew you already thought of that (or was pretty darn sure you'd already considered all of that). Was clarifying for others who may not have considered such.

Here's something I was just thinking of, due to another thread, but how many hand-offs/reliances (if any) are there in PMMERGE?

Or are you asking about how many reliances that PMMERGE has on other parts of the system?
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

RobertM

Quote from: demetrioussharpe on 2011.05.12, 05:25:24
Or are you asking about how many reliances that PMMERGE has on other parts of the system?

Nah, you've got it covered...




On to a couple other things not mentioned, but needed.

(1) code that handles swapper.dat needs to be rewritten to take advantage of JFS (ie: greater than 2GB)



Below here are things reported elsewhere, but that I have no knowledge of, so I cannot confirm their validity.



(2) It appears (or so people at EDM/2 and elsewhere have reported) that the OS/2 kernel manages far more than 4GB of in-use RAM. (this is also why the swapper.dat code is problematic).

Inotherwords, while certain arenas are both (a) fixed in size and (b) for all intents and purposes, limited by whatever that size is; other arenas apparently are not.

This is apparently due to something rarely talked about. OS/2 "mixes and matches" use of both the flat memory architecture (ie: limited to 4GB) and the paged architecture. By paging userspace memory needs, per the post here, success has been claimed for using up to 256GB on AMD CPUs. And per this OS/2 Voice article on the kernel, it supposedly "may" do so up to the 64TB limit imposed by the x86 CPU architecture. They cite some use of that ability here (quoted from the article):
"In the old 16/32 bits model one could already run, say, 50 processes using 100 MiB of protected memory (total 5 GiB). And now we can run very big processes each using up to 1-3 gigabytes of protected mode memory concurrently."

Of course, if this is true, the major limitation still resides in the maximum size of the swap file - and of course, OS/2's ability to properly utilize the paging architecture of the particular CPU.



Here's a page with a few links to others' work on figuring out the kernel, which you may have already found:
http://en.ecomstation.ru/projects/developer/?action=kernel


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


demetrioussharpe

Quote from: RobertM on 2011.05.14, 20:47:48
Inotherwords, while certain arenas are both (a) fixed in size and (b) for all intents and purposes, limited by whatever that size is; other arenas apparently are not.

To be honest, I'm still not sure of the original purpose of splitting the memory address range into arenas...
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

RobertM

Quote from: demetrioussharpe on 2011.05.14, 21:20:53
Quote from: RobertM on 2011.05.14, 20:47:48
Inotherwords, while certain arenas are both (a) fixed in size and (b) for all intents and purposes, limited by whatever that size is; other arenas apparently are not.

To be honest, I'm still not sure of the original purpose of splitting the memory address range into arenas...

(The major aspect): Protection. OS/2 uses Ring 0, 2, and 3 to enforce the various protection schemes that are part of the x86 architecture post 386.


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


demetrioussharpe

Quote from: RobertM on 2011.05.14, 23:35:53
Quote from: demetrioussharpe on 2011.05.14, 21:20:53
Quote from: RobertM on 2011.05.14, 20:47:48
Inotherwords, while certain arenas are both (a) fixed in size and (b) for all intents and purposes, limited by whatever that size is; other arenas apparently are not.

To be honest, I'm still not sure of the original purpose of splitting the memory address range into arenas...

(The major aspect): Protection. OS/2 uses Ring 0, 2, and 3 to enforce the various protection schemes that are part of the x86 architecture post 386.

It's a rather odd scheme, it seems to be overcomplicated. All that was really needed was rings 0 & 3. Protection is provided between memory spaces on other OSes without this arena concept. So, is there something else that arenas bring to the table?
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

RobertM

Quote from: demetrioussharpe on 2011.05.15, 16:49:45
Quote from: RobertM on 2011.05.14, 23:35:53
Quote from: demetrioussharpe on 2011.05.14, 21:20:53
Quote from: RobertM on 2011.05.14, 20:47:48
Inotherwords, while certain arenas are both (a) fixed in size and (b) for all intents and purposes, limited by whatever that size is; other arenas apparently are not.

To be honest, I'm still not sure of the original purpose of splitting the memory address range into arenas...

(The major aspect): Protection. OS/2 uses Ring 0, 2, and 3 to enforce the various protection schemes that are part of the x86 architecture post 386.

It's a rather odd scheme, it seems to be overcomplicated. All that was really needed was rings 0 & 3. Protection is provided between memory spaces on other OSes without this arena concept. So, is there something else that arenas bring to the table?

Tried, tested, stable, working, hardware enforced protection - as opposed to software based in such products as Windows non-working version. I have no idea how Linux's approach fairs.


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


RobertM

I also believe it is somewhat related to how the paging system and flat virtual memory access system are used. Sadly, my knowledge on this is old, and with no first hand experience about the underlying code base... the only OS/2 code I've been privy to is in the print subsystem and portions of the GDI/GPI subsystems that are related.


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


demetrioussharpe

Quote from: RobertM on 2011.05.15, 18:50:45
Quote from: demetrioussharpe on 2011.05.15, 16:49:45
Quote from: RobertM on 2011.05.14, 23:35:53
Quote from: demetrioussharpe on 2011.05.14, 21:20:53
Quote from: RobertM on 2011.05.14, 20:47:48
Inotherwords, while certain arenas are both (a) fixed in size and (b) for all intents and purposes, limited by whatever that size is; other arenas apparently are not.

To be honest, I'm still not sure of the original purpose of splitting the memory address range into arenas...

(The major aspect): Protection. OS/2 uses Ring 0, 2, and 3 to enforce the various protection schemes that are part of the x86 architecture post 386.

It's a rather odd scheme, it seems to be overcomplicated. All that was really needed was rings 0 & 3. Protection is provided between memory spaces on other OSes without this arena concept. So, is there something else that arenas bring to the table?

Tried, tested, stable, working, hardware enforced protection - as opposed to software based in such products as Windows non-working version. I have no idea how Linux's approach fairs.

Even still, many other OSes use only rings 0 & 3, because all that really matters is if the machine's running in user mode or kernel mode. All 4 modes offered by x86 aren't really necessary. In face, afaik, OS/2 only uses 3 out of 4 of the protection levels. I'm more than confident that it's using one level too many. It needs to get off the fence. Either the process is in the kernel or it's outside of the kernel. And if it's outside of the kernel, there's no real reason for it to be running under any level other than ring 3.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

demetrioussharpe

Quote from: RobertM on 2011.05.15, 21:33:37
I also believe it is somewhat related to how the paging system and flat virtual memory access system are used. Sadly, my knowledge on this is old, and with no first hand experience about the underlying code base... the only OS/2 code I've been privy to is in the print subsystem and portions of the GDI/GPI subsystems that are related.

I understand taking advantage of the platform that you're running on. However, it just feels as if they'd gotten kinda carried away & tied themselves too tightly to x86. Perhaps they should've just stuck to the basics in some aspects.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

demetrioussharpe

Just a heads up. If I understand correctly, 16-bit code won't execute on a 64-bit machine in long 64-bit mode. I'm not sure yet about 32-bit code. But, with that being the case, there's going to be a huge push to create a standard for 64-bit functions, structures, & general data. In short, 64-bit OS/2 will need to be standardized. After soliciting advice from others in the OS/2 community, I was advised to try using elf in 64-bit mode for OS/2-64. Does anyone have an issue with this? Keep in mind, this is a long term project that entails creating the whole software stack from development tools to OS to drivers to APIs to applications. In essence, a brand new operating system & ecosystem. Is there anyone else willing to contribute?
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!

RobertM

Correct, 32 bit code should execute fine. 16 bit code will not execute. In my laboriously overly verbose way below, that's what I was trying to mention when I was asking about intercepting any 16 bit calls and executing them as (at least) 32bit - hence the "Odin-like" suggestion.


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


demetrioussharpe

Sorry it's been awhile. I haven't been able to work on any kernel work because of a combination of preparing to move & medical issues. I'm scaling back most of my development efforts & sadly, this is one of the projects that's under the ax right now. Perhaps I'll return to this project once I'm doing better, health-wise.
The difference between what COULD be achieved & what IS achieved
is directly relational to what you COULD be doing & what you ARE doing!