Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Christopher Brumme - Is a managed kernel possible?

Download

Right click “Save as…”

Christopher Brumme, architect on the .NET CLR team, talks about the long-range future of Windows. Charles Torre wants to know if a managed kernel is possible.

Tag:

Follow the Discussion

  • Woot.. AND after we have this wonderful kernel, why not store everything in XML. [/Sarcasm]

    You guys seriously live in your own little magical world where CPU is infinite all you do it comes up with thousands of new ways to make our computers EVEN slower. There is a need to find a good balance between speed and security, building the kernel in this way is not the answer. It is like the one step forward two steps back approach.

    Seriously, lately it seems like increases in CPU and RAM have only been used to let software get fat and programmers lazy. The XML parser is example 1 in that case.

  • barlo_mungbarlo_mung w00t
    First I think they will be going in the other direction, allowing drivers to run in user mode.  That is what they were saying at WinHEC anyhow.  That in the Longhorn time frame we would see user mode driver support in the WDF.
  • CharlesCharles Welcome Change
    Yep. This is a rather esoteric notion at this point. But who better to ask than Chris Brumme? At any rate, buggy kernel mode processes are primarily responsible for causing macro kernel-based operating systems to crash.

    Making it possible to move some kernel mode drivers up into user mode is certainly moving in the right direction.

    You should see some user mode driver support in the WDF come Longhorn.

    Keep on posting,

    Charles
  • eddwoeddwo Wheres my head at?
    That sounds like what this guy is working on.

    "Galen Hunt
    Researcher

    I am a Researcher leading a project to build a prototype research OS kernel, called Singularity, on managed code. We are using Singularity to exploring issues of system reliability. In this context, I loosely define reliabity as, "the system never does anything unexpected or unanticipated by the its designers, developers, administrators, or users."

    Sounds very interesting, but I imagine it'll be several years before this gets anywhere near a commercial product.


  • Sorin DolhaSorinD Sorin Dolha

    In my opinion,

    Windows' kernel should definately become .NET-based in the future, when hardware will be better. Old Win32 kernel compatibility should be provided as an emulated environment, just like is DOS today in Win32. Getting the kernel to .NET is a needed step forward, and even if the computers will run it slower, it will be extremely benefic especially for developers (including drivers developers or so, which today have many headaches with developing on the not-managed core of Windows). Personally, I always exchange speed on elegance, therefore, I vote for it: bring .NET to the Windows core as soon as technically possible and economically possible...

    Beside those thoughts, I think that Micrsoft should talk with Intel, AMD or so, to create .NET-supporting processors, processors which hopefully will be able to run MSIL directly, therefore, very fast! What do you think about this hardware change to come together with the new .NET Windows core?

  • Has anyone manufactured (or is anyone planning to) a cpu that can execute IL directly? surely there's no speed compromise on a CPU that could do that?
  • This is insanity. I mean if you were serious about sacrificing speed for security then why not look at a Micro-Kernel? I mean the big draw-back of that is you have a speed drop (nowhere near how much this would) but is more secure because the modules can't damage the core kernel.

    It would also load super-fast and be super-stable!
  • damphlett wrote:
    Has anyone manufactured (or is anyone planning to) a cpu that can execute IL directly? surely there's no speed compromise on a CPU that could do that?


    Transmeta has already demonstrated a processor that can execute Java bytecode.
  • I find this concept very interesting. I've thought about it, but didn't give it a seroius thinking through. If Windows' Kernel DID become .NET based, I'd like it if some applications were open source (like Paint, Word Pad, Calculator, etc) so people could build on those and make Windows even better by turning MS Paint into something that might do some of the stuff Photoshop does or Fireworks. We could turn those basic apps into something really special (ahem, fix the JPEG compression, make it so you can select created objects and move them around at anytime, etc).

    A .NET kernel... Sounds interesting!
  • wilsone8wilsone8 Please don't make me a manager
    Manip wrote:
    This is insanity. I mean if you were serious about sacrificing speed for security then why not look at a Micro-Kernel? I mean the big draw-back of that is you have a speed drop (nowhere near how much this would) but is more secure because the modules can't damage the core kernel.

    It would also load super-fast and be super-stable!


    How will a micro-kernal load any faster?  If I move a bunch of code that is now in kernal space into user space, how does that decrease the total amount of code I have to execute in order to startup?

    As for the big push to move everything into user space, remember that NT originally started out that way (back in the NT 3.51 days).  When they made the switch to 4.0, Microsoft made the decision to move the GDI portion into the kernal in order to speed things up significantly (this was the same time they made the switch to the win9X interface, which required a heck of a lot of horse power in those days).  Ever since, the trend has been to continue to move into the kernal.  With Windows 2003 for example, IIS came with a kernal mode driver for processing http requests. Again, there is the tradeoff between performance and the beautiful abstraction that is user space. 

    I for one think that the OS is such a core component that sqeezing every ounce of performance out of it should be a must.  After all, anone who has profiled their own code knows that for the majority of applications, only a small percentage of time is ever spent running application code.  System code will typically take up at least an order of magnitude more processing time.
  • The core kernel is dramatically smaller. So the core kernel will load faster, could also be better optimized for a speedy load (appearance of speed to the user). Also, it is easier to pick and choose what is in the kernel and thus less should be loaded at all.
  • CharlesCharles Welcome Change
    Manip wrote:
    I mean if you were serious about sacrificing speed for security then why not look at a Micro-Kernel? I mean the big draw-back of that is you have a speed drop (nowhere near how much this would) but is more secure because the modules can't damage the core kernel.

    It would also load super-fast and be super-stable!


    What makes you so sure that a micro-kernel would be faster than a partially managed macro-kernel?

    Certainly, one of the primary reasons Unix and NT went with the macro-kernel architecture is speed, as you point out. 

    In a micro-kernel, communication from the kernel to a device driver requires a process switch. This incurs a large performance penalty. In general, micro-kernels are known for their stability and to some extent reliability, not their performance. You'd have a hard time building an OS like Windows on top of a micro-kernel.

    There is a happy medium out there and I think it's probably in the area of a partially managed kernel plus more support for usermode drivers. There are some really big brains working on this problem right now. I'm certain we will see some real innovation in this area within the next 10 years. 

    As always, time will tell.


    Keep on posting,

    Charles
  • rhmrhm
    Wow, it's been a while since I heard anyone promoting microkernels. Like '90s style Smiley

    The microkernel dream doesn't really pan out in reality. Apart from the performance issues Charles mentions, it is quite feasible for a device driver to crash the machine whether it's running in kernel or user mode because it by definition needs to have access to the hardware. OK, you could make the driver go through kernel to sanity-check all the IO operations, but that would make it yet slower still.


    As for other people's comments about hardware to directly execute bytecode... Sun tried this with Java and it's not really practical. The stack based architecture of the JVM and CIL isn't designed for hardware execution. That's not to say you can't design hardware that would execute the code, but rather that you would have trouble doing all the speculative and out-of-order execution that modern CPUs do. You could of course translate the CIL into another more conventional register-based instruction set behind the scenes and then take advantage of the huge amount of existing knowlege about how to execute that quickly, and this is what Trasmeta do. If you go this route though it's difficult to see what benefit you then have over a regular JIT like the CLR.
  • wilsone8wilsone8 Please don't make me a manager
    Manip wrote:
    The core kernel is dramatically smaller. So the core kernel will load faster, could also be better optimized for a speedy load (appearance of speed to the user). Also, it is easier to pick and choose what is in the kernel and thus less should be loaded at all.


    Yes, the core kernal would load faster.  But overall system startup time would not change very much if at all.  I have to load things like the graphics system at one time or another.  If it is in the kernal or in user space, I have to execute roughly (order of magnitude here) the same number of instructions.  Again, how is this going to change my overall startup and run time performance?  Who cares when the core kernal is booted up?  I care when I can do actual work:)
  • mertsakaryamertsakarya Mertiko
    I definetly think that Kernel should be managed in the future (probably in 64 bit or 128 bit era).

    If Microsoft is thinking that .Net is the future, than I believe that, when the time comes, the whole Operating System will be written with .Net managed code, but I don't know, if the operating system will still be called "Windows" at that time.

    Time's going very fast (and faster), we gotta catch it.

    How'bout this: Managed Intel CPUs Wink

    Mert

Remove this comment

Remove this thread

close

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.