[Gerson]

Hi,
I'm sorry if this has been talked about before, but I didn't see a thread about it when searching.
In the (old) article someone mentioned recently about NT 3.5.1 vs. NT 4, there was a discussion about moving the NT graphics system and window manager into the kernel. Microsoft did this with NT 4 to improve performance.
I DON'T want to talk about how slow or fast OS X is and get into another flame war; PLEASE.
All I'd like to ask is, could Apple do this? Why would it be a good or bad idea?
In addition, what exactly is in the kernel now? I'm not a programmer, so I'm sorry if these are naive questions.

I'm also curious; the article mentions "rings" of processor privilege levels; do PowerPC chips have the same sorts of privilege levels as Intel chips?

Anyway, thanks in advance. And here's the link to the article about NT: http://www.zdnet.com/pcmag/features/...16/ntintro.htm

[Riemann Zeta]

I don't think that this is possible with OS X. However, the best thing to do would be to recode all the mission-critical applications (such as Quartz, Finder, Loginwindow, etc...) as Mach-O applicaitons, that way they would be running at maximum speed and optimization.

[mbordas]

Originally posted by Riemann Zeta:
I don't think that this is possible with OS X. However, the best thing to do would be to recode all the mission-critical applications (such as Quartz, Finder, Loginwindow, etc...) as Mach-O applicaitons, that way they would be running at maximum speed and optimization.

I could be wrong about this, but I think the finder is Mach-O carbon, and quartz and loginwindow are cocoa

------------------
I don't suffer from insanity, I enjoy every minute of it.
http://bordas.dhs.org

[ntsc]

I am no programmer so take what i say with i pinch of salt

The entire graphics sub-system is neither Carbon or Cocoa since it is lower level according to Apple's chart .

As far as i have heard putting the graphics layers in with the kernal would not be such a good idea since this increases the chance that the whole OS can crash since there is more to go wrong. Correct me if i'm wrong but surely if this was the set up then if the window manager crashed it would probably bring down the whole OS. Quartz will get much faster I think when Apple figure out how to hardware accelerate it as most of the calculations including window resizing are currently done by the CPU.

As i say i'm no programmer this is just what I have pieced together

------------------
"It is easy to be brave from a safe distance"
-Aesop

[macvillage.net]

They won't do this for a number of reasons:

1. If Quartz has an error, it could be more of a problem, now we have protected memory since they are separate

2. This allows for easy expansion. Now Quartz could easily be updated without effecting Darwin.

I do think this will get faster, yes they are still working on enabling hardware acceleration (ATI cards are not really suppored yet). Don't forget that it is brand new. New techniques for doing things more efficient just evolve over time.

------------------
Robert Accettura
Owner/Webmaster of

[Gerson]

ntsc--
That's interesting....but what good is OS X without a window manager? I mean, an advanced user with another computer could telnet in, but for the typical user, if the graphics system and/or window manager crash, the computer has for all practical purposes crashed. Also, if what that NT article describes is similar to what OS X does, no matter how optimized Quartz is, there will still be the overhead of routing API calls from an app to the kernel and out again to the graphics system.
That last sentence could be totally ridiculous; how DOES an application make a call to Quartz?
Also, I imagine that moving graphics into the kernel would be a massive, massive task (OS X 2.0 if that) but what would make it actually impossible, Riemann Zeta? I'm just curious.

[Angus_D]

OS X without Window Manager and so on is called Darwin. There are at least a few people who use it + XFree86 and get some definite work done on it. There's even a group who are making a fully-fledged distribution out of it (GNU/Darwin).

[Gerson]

Angus_D,
I didn't mean to dismiss Darwin. Yes, Darwin is a real, useful and used OS. I just meant that to a person like me, for example, who isn't going to use the computer except through the GUI, having the GUI crash is pretty serious.

[Mactoid]

Originally posted by Gerson:
Angus_D,
I didn't mean to dismiss Darwin. Yes, Darwin is a real, useful and used OS. I just meant that to a person like me, for example, who isn't going to use the computer except through the GUI, having the GUI crash is pretty serious.

true, if you have no CLI experience, than Quartz running amok would be pretty serious problem, but that is no reason to to conclude it's okay to move it into the kernel space. The graphics layer should remain seperate from the kernel. Apple is trying to do the Right Thing(tm) with the OS this time, and sometimes that comes at the expense of speed. I applaude them for that. some speed issues seem pretty important right now, but will be irrelevant a couple years down the road. if we stick the GUI in the kernel now, we will be stuck with that decision long after we are reaping any benefits from it.

[Gametes]

Another, alternative solution to the apparent end-user experience of a GUI crash equating with a system crash would be to move the force-quit mechanism into the kernel space, and expand its options.

To clarify: apple+opt+esc ought to be as it is now: always functional. The window it brings up must be moved into kernel space, so that so long as the computer is running, no matter what, you can bring it up. then Just give it tabs labelled "User, Aqua, Darwin". The user can then quit any app that's giving them trouble, be it OmniWeb or Mail, the Finder or Dock, or netinfod or Window Manager.

Apple cannot afford to move the whole Graphics system into the Kernel space because, ultimately, that process is not crashproof, which the OS must be. The days of crashing are over, Apple wants.
Instead, this method will permit the already in-place layering system to allow the user to kill any miscreant process. Goodbye crashes.

Now if they can just get the System up to speed in deciding for itself whether it's crashed, and then fixing itself...

------------------
you are not your signature

Apple should *not* move the graphics subsystem (Quartz) into kernel space. NT 4 did it, but it doesn't give all that much of a performance increase. The speed detriment currently is only present because Quartz and the kernel have to communiate back and forth and the processor has to switch from Supervisor to User mode when executing Kernel or Quartz code respectively. It's not that big of a hit. Like someone else said, if this happened, we'd be living with the ramnifications for a long time. Once its in, its hard to get out.
This complicates the kernel immensely. The reason for Mach in the first place, indeed all microkernel architecture OSs is to *abstract* and create layers. Theoretically, if you have a Mach microkernel, you can run *two or more* Mach-based *operating systems* on the same computer at the same time and they wouldn't even know it. This is cool but of course no one uses it. But I digress. The layered/abstraction approach that is taken with Mach insulates the different parts of the OS from each other, yielding more stability and compatibility. The Quartz code doesn't care if the Kernel code has changed, because they are abstracted from each other through well defined interfaces (ways to communicate between each other, message passing). Monolithic kernels (linux, etc) can be a horrible mess when APIs change in Kernel code. Mach can be horrible too though.

Mach was built to run as a compact, fast, efficient kernel that arbitrates between different "servers" that provide services to the User and other applications. In this respect, the kernel is fast and kernel operations are fast, but the overhead of communicating between the different servers rather than interfacing directly with them is what slows it down a bit.

As Gametes said, it would be extremely useful if Apple would move Force Quit stuff into Kernel space or *something* so that it's independent of the Window Manager and Quartz. If you have a full screen OpenGL app that goes south, try bringing up Force Quit. You can't even see it.

Now since the video drivers are in kernel space (as .kexts) it wouldn't be that difficult to switch pages of vram and switch in a page with a simple window that displays running processes to kill. Of course this is non-trivial, but it's not too hard. Or just a text screen for God's sake, something that would let us kill processes even after the Window Server's been trashed. Because if you don't know telnet, the machine is frozen for all intents and purposes. How many users are going to know to telnet in when something like this happens and kill the window server to restore everything? Not many.

Even WinNT (2000) has this problem sometimes. Try Tribes2 for example. When it dies, there's many a time when you can't press Ctrl-Alt-Delete and get that nice task manager. But NT seems to be able to kill bad apps far more often than OS X, even with full-screen OpenGL things that crash.

[Millennium]

No, no, a million times no! While moving graphics into the kernel gave NT a modest performance boost, it was at the extreme costs of stability and security. Nothing should go into a kernel that can possibly be done outside it. Granted, Mach breaks this rule at points too, but it's not anywhere near as bad about it as NT is. Moving graphics into the kernel would not be worth it. Trust me on this.

[Gerson]

Wow, thanks for the info! I'm curious: where can I learn what exactly IS in the Mach microkernel for OS X?

[lgerbarg]

Originally posted by Gerson:
Wow, thanks for the info! I'm curious: where can I learn what exactly IS in the Mach microkernel for OS X?

Just for reference, while OS X does use Mach 3.0 as base, OS X is not a microkernel OS. In OS X the bsd code as well as IOKit are staticly linked into the kernel, they are not in seperate memory spaces, or even seperate entities in the same space. They communicate through function calls, not messages or shared memory.

This gives a significant speed boost. It also means that it is a monolithic kernel whose code is organized like a microkernel OS, and dirextly exports both BSD Unix and Mach interfaces.

Oh, I am way against moving graphics in the kernel, I basicly agree with the fact that the performance gain is minimal, and it has serious consequences.

Louis

------------------
Louis Gerbarg
Darwin Developer

[dogzilla]

Originally posted by Gametes:
apple+opt+esc ought to be as it is now: always functional. The window it brings up must be moved into kernel space, so that so long as the computer is running, no matter what, you can bring it up. then Just give it tabs labelled "User, Aqua, Darwin". The user can then quit any app that's giving them trouble, be it OmniWeb or Mail, the Finder or Dock, or netinfod or Window Manager.

This makes hella sense to me. Any idea why Apple doesn't simply do this? Being able to restart Aqua sounds like a downright useful thing to me. Are there any negative side effects?

[sadie]

Gametes suggested:
apple+opt+esc ought to be as it is now: always functional. The window it brings up must be moved into kernel space, so that so long as the computer is running, no matter what, you can bring it up. then Just give it tabs labelled "User, Aqua, Darwin". The user can then quit any app that's giving them trouble, be it OmniWeb or Mail, the Finder or Dock, or netinfod or Window Manager.

dogzilla replied:
This makes hella sense to me. Any idea why Apple doesn't simply do this? Being able to restart Aqua sounds like a downright useful thing to me. Are there any negative side effects?

If Quartz or the Window manager goes totally Kafooii, what's the chances that actual programs are still running? Say I'm working on something in Photoshop, about to save when the machine apparently crashes from the graphics layer. What are the chances that my work is recoverable?

If it could automatically detect this, even better. So if my machine crashes, i just need to go get a cup of coffee, come back and carry on working. Wouldn't that be nice?

Originally posted by sadie:
If Quartz or the Window manager goes totally Kafooii, what's the chances that actual programs are still running? Say I'm working on something in Photoshop, about to save when the machine apparently crashes from the graphics layer. What are the chances that my work is recoverable?

Try killing your WindowServer process and find out. Although you don't have to bother - I'll tell 'ya. It's just like a very brutal logout. All applications started in that desktop session are killed, the loginwindow daemon restarts the WindowServer, and you log in all over again. If you have your computer set up for auto-login (default), you will appear to have just logged in. System daemons (web serving, print serving, Apple File Sharing, etc...) continue to run un-affected.


Currently, there is no way to get the applications to stay around and re-attach (or pop up a save dialog, etc...) when the new WindowServer comes on line. That would ne nice, though.

[dogzilla]

Originally posted by SawThis:
Currently, there is no way to get the applications to stay around and re-attach (or pop up a save dialog, etc...) when the new WindowServer comes on line. That would ne nice, though.

Ahhh, bummer. Guess it has limited utility unless you're running a webserver or file server or something.

[P]

The Window manager should most certainly NOT be moved into the kernel. That would be huge blow to X as a server. NT 3.5.1 is a lot more stable than NT 4.0, and mainly because of the desicion to grow the kernel from 2 MB or so to 19 MB in 4.0 (and to 35 in 2000)

I think parts of Quartz run as a kernel extension, because all graphics drivers are type .kext, kernel extensions. BTW, the version of the Rage 128 driver in 10.0.2 is 0.1. Maybe not that optimized, eh?

Run "sudo kmodstat" to see what kernel extensions you have loaded.