• 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

New kernel

Started by AAA, 2008.11.07, 17:05:07

Previous topic - Next topic

AAA

Looks like a new kernel is coming.

It would be great if those who are interested in this shared their opinion regarding what they want to see added and/or improved in a new kernel.

I believe, this would help the developers.

djcaetano

I don't know if this is possible, but an improved support to memory management would be great.
The kernel we are using now is too damn limited when it comes to upper memory management. It is very common (mainly when using ODIN apps) receive an "out-of-memory" error when only 300MB out of 2GB are being used by applications.

I don't know if it is possible, but another cool thing would be a way to update PATH, LIBPATH and other PATHs system-wide without the need to reboot the system.

Well, these are my first two wishes. :)

MrJinx

Being able to load and unload at least some .sys & .add type drivers without a reboot would be great.
Refreshing config space changes and snoop. All those things reboots are made of when trying to develop drivers and tweak resources. Since we are asking for the world here. ;D

RobertM

Quote from: MrJinx on 2008.11.07, 23:12:58
Being able to load and unload at least some .sys & .add type drivers without a reboot would be great.
Refreshing config space changes and snoop. All those things reboots are made of when trying to develop drivers and tweak resources. Since we are asking for the world here. ;D

I think that may be a nice option for the developer release of the kernel, but am happier with those drivers unchangeable during normal operations. The system is more secure that way - then with access rights applied to the config files, it would be very difficult to "hose" a system from an external (or externally loaded) location.

Though, for perception purposes, it is a nice thing to have, as end-users are used to such functionality on Windows. At the very least, screen resolution changing without reboots would be a nice touch. The rest I could do without.

Rob


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


cytan

Much, much larger shared memory space than we have now (512MB). OpenOffice, Mozilla, etc. all take up so much shared memory space that after a while shared memory gets exhausted or fragmented so that these apps cannot start and a reboot is required.

See the OS/2 voice article : http://www.os2voice.org/VNL/past_issues/VNL0708H/feature_3.html

cytan

Saijin_Naib

I vote for shared memory and Resolution/Bit-depth changes. That is insanely important especially on laptops or other computers where you hook up an external display for use on a projector.

RobertM

Quote from: Saijin_Naib on 2008.11.08, 00:58:23
I vote for shared memory and Resolution/Bit-depth changes. That is insanely important especially on laptops or other computers where you hook up an external display for use on a projector.

Hi Saijin/all,

I just posted this elsewhere in a slightly divergent topic - but it fits this category better:


Regarding the kernel (from http://www.os2voice.org/VNL/past_issues/VNL0708H/feature_3.html)...

"The kernel itself could address 64 terabytes of virtual memory. For instance to keep track of the virtual memory usage of the other protected mode processes that were not active. But this is not visible to the protected mode programs' virtual memory world. They experience their 4 GiB world as all there is. Unless they use some special kernel APIs like Theseus."

So, apparently, not just can the existing kernel see 64 terabytes, but programs calling those kernel APIs can as well.

Hmmm..... this article seems to confirm what I read on EDM/2 a while back.


Question is, what does that mean for the current kernel? Are those APIs usable for general-use type programming? And does that explain how OS/2 seems to map hardware (at least on my machine) outside of the 4GB arena?


Robert


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


miturbide

To be open source will be great. (or at least that the source code can be available too). I will be a tragedy that a new kernel could turn into abandonware in the future since it is proprietary.
Martín Itúrbide
OS2World.com NewsMaster
Open Source Advocate

Skype - martiniturbide
Google Talk - martiniturbide@gmail.com

The Blue Warper

#8
Hi all!

AAA, IIRC, you usually report development news related to the OSfree project.  They're working very hard, as it seems.  So I'd like to thank them for all the efforts they're putting into this huge project.

As for my wishes, well, I have a not-so-short list of them.  But as we (actually, OSFree Team...) are in an earlier stage, I'd try to keep it short.
So, these are my wishes (not necessarily in the following order):

1) Fixing the SIQ problem at last.  I wonder why this wish wasn't mentioned in any of the previous posts...  Yes, Warp4 FP15 is more stable than Warp4 GA, and eCS is in general more stable than Warp4 FP15 (never had IBM OS/2 Warp 4.52 (MCP) though).  But we should get rid of this somehow.  I once read this shouldn't be too hard to fix or implement.
2) Providing a sort of Hardware Abstraction Layer.  This could result in the long term in better performance of the hardware sub-systems: video, audio, CPU, ACPI and so on.  AFAIK, the PSD-approach that IBM followed in its OS/2 server releases (and eventually in the desktop clients) looked like a sort of HAL.
3) The ability to restart PM (Presentation Manager) without rebooting.
4) Implementing in the kernel callings to the newer instruction sets that both Intel and AMD introduced in their CPUs after the Pentium era.
5) Compiling the kernel for CPU architectures newer than Intel 386...  I'd say Pentium architecture as a minimum.  Yes, I know the OS/2 kernel was thoroughly 'hand-written' around the 386 architecture, by extensively using assembly code.  But, as the new kernel should be compiled nonetheless, and this could result into losing some of the code optimizations that IBM put into the kernel at that time, why don't try to compile the new kernel with the CPU optimizations switches?  OSfree OS2LDR required a Pentium CPU architecture after all, so chances are that they'll enter this path for the kernel too.
6) As for memory management, a better way of handling the memory, by giving apps the space they need, would be fine.  But what RobertM said about "64 terabytes of virtual memory" is potentially significant, so OS/2 kernel might in fact be, in a certain way, ready for this memory amount.
7) Kernel-side support for hibernation (this is especially useful for notebooks).

These are OS/2 kernel areas where I'd personally wish to see some improvements.  They are not the only improvements possible (and I surely agree with what was said earlier in the other posts), but I think they're worth to be taken into consideration by the developers.
Although I'd say that for now the best thing that could happen to the OS/2 kernel is that it is being developed again.
My best wishes for your efforts!

Fahrvenugen

Did I miss something?  I don't recall reading anywhere about a new kernel being developped, other then the efforts of OSFree and (possibly) Voyager.

The only recent thing I saw was that eCS 2.0 RC6 would come with the SMP kernel, but the SMP kernel has been available for a while now.

BigWarpGuy

Would K42 from IBM be considered a new kernel?

mobybrick

Hi,

It's great to even think that there are those who are working hard on this to improve the OS for everyone.

I think we should be realistic and hopeful at the same time. There are, however, IMHO a number of important improvements that would be good to see to start with:

1. Support for power management/cool-n-quiet/CPU throttling across all ranges of new CPUs, chipsets and kernel types.
2. Improved assistance in the kernel for ACPI + VPIC support

Thereafter, second priority things should IMHO be:

3. Support for PAE and booting and using memory >4Gb
4. Enhanced shared memory support (moving more stuff to high memory) so that systems with large amounts of RAM can use it more

Longer term, new things will become important:

5. Support for IFS >2Tb (will need updates to IFS, DMDs and kernel)
6. 64-bit execution support (will mean elimination of all remaining 16-bit code in the kernel, IFSs and networking!)

But I don't yet see how these things will be achieved without access to the kernel source and documentation. But I'd love to be proved wrong!!

Regards,
Moby

jjurban

I'd like to see an expansion of "shared memory" available to users.  I'd like to see settings in CONFIG.SYS which can set the limits on shared memory.

My Object Rexx programs (as well as Chuck McGinnes's eCS maintenance Tool) crashes with SYS3175 in Rexx.dll.  I think it's because of shared memory limitations.

John



warpcafe

Hi all,

I agree with Fahrvenugen... and I am quite shocked to see that apparently nobody has asked before posting their wishes: Where have you got this information from, AAA ?

Cheers,
Thomas
"It is not worth an intelligent man's time to be in the majority.
By definition, there are already enough people to do that"
- G.H. Hardy

RobertM

Quote from: jjurban on 2008.11.10, 13:55:41
I'd like to see an expansion of "shared memory" available to users.  I'd like to see settings in CONFIG.SYS which can set the limits on shared memory.

My Object Rexx programs (as well as Chuck McGinnes's eCS maintenance Tool) crashes with SYS3175 in Rexx.dll.  I think it's because of shared memory limitations.

John

John,

That actually seems to be a horrendous memory leak/bug in oREXX. A while back I discussed it with Serenity, and they were considering implementing the "solution" I had suggested until oREXX could be fixed.

That "solution" is simple. Downgrade oREXX to the earlier version on Hobbes. Same functionality (ie: the new calls), much slower memory issues.


I can replicate what you are describing with the version of oREXX that came with eCS v1.2MR using a very small amount of memory (large use of stems will cause it in no time, while not having used very much memory at all) - while the same code (1) runs far faster in cREXX, and (2) has never crashed. Under the earlier version of oREXX on Hobbes, the code is much more stable, and instead of crashing the REXX dll in a few minutes, can last days or weeks (but still eventually gets to that point) - which seems to indicate a big leak.

I am pretty sure of that because, each REXX program is simply a web server script, that gets loaded and exited. When I ran them separately from the commandline and closed the commandline and reopened, there was still a certain amount (of ever increasing) memory that was not freed - which eventually leads to the REXX dll crashing. Minutes to hours on the current version... days on the older one from Hobbes. Thus again, I suspect part of the issue is a memory leak (and worse, in the case of the oREXX that came with eCS 1.2) in that ever so critical memory arena.

Robert


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