Page 2 of 7 FirstFirst 1234 ... LastLast
Results 11 to 20 of 61

Thread: "The World's Most Highly-Assured OS" Kernel Open-Sourced

  1. #11
    Join Date
    Jan 2013
    Posts
    10

    Default

    Quote Originally Posted by kaprikawn View Post
    I would be interested to know how many lines of code make up this kernel versus the Linux kernel.

    (I'm aware you can get this information fairly easily through Git, but I don't know how and I'm at work so haven't got time to research).


    I don't think the aim the same hardware coverage. Drivers alone are a huge part of linux kernel.

  2. #12
    Join Date
    Feb 2012
    Location
    Kingston, Jamaica
    Posts
    316

    Default

    Quote Originally Posted by kaprikawn View Post
    Thanks, wow that's quite something. A quick google search shows the Linux kernel was over 15million lines of code in 2011. I suppose it's a lot easier to keep code secure when there's so few moving parts.

    For limited use cases I'm sure this would be good to use. Though with so few lines of code I'm assuming there's no hardware drivers. Imagine getting wi-fi up-and-running using this!
    There are a few drivers available for various platforms. The drivers are run in userspace so so they do not add to the complexity of the kernel. With the right layers above, it could be used for the same scenarios that Linux is used for. Of course, platform, libraries and driver support aren't even near the same level that Linux is.

  3. #13
    Join Date
    Jul 2010
    Posts
    522

    Default

    Quote Originally Posted by by.peroux View Post
    I don't think the aim the same hardware coverage. Drivers alone are a huge part of linux kernel.
    Yeah, microkernels as this one will usually be running drivers in user space anyway.

  4. #14
    Join Date
    Oct 2010
    Posts
    469

    Default

    You can always use DDEKit with linux drivers on an L4 kernel; probably not without possible bugs, but if you're doing something like that you would probably have time to check for bugs yourself.

  5. #15
    Join Date
    Feb 2012
    Location
    Kingston, Jamaica
    Posts
    316

    Default

    Quote Originally Posted by Nobu View Post
    You can always use DDEKit with linux drivers on an L4 kernel; probably not without possible bugs, but if you're doing something like that you would probably have time to check for bugs yourself.
    It's not a given that DDEKit works for any L4 kernel. seL4 currently does not use/support DDEKit. DDEKit is used with older and newer versions of Fiasco, Minix, Hurd and Genode. Note that DDEKit is different for each of these OS/Kernels.

  6. #16
    Join Date
    Jan 2009
    Posts
    1,481

    Default

    Those l4 kernels are pretty impressive. These are what we need for IoT, along with rewritten userspace in "safe language" (for some value of safe). The BIG job will be rewriting drivers (at least certain drivers for devices like network adaptors (including Bluetooth)) so as to make the system as reliable as possible.
    The Genode framework is almost perfect for this sort of project but its security isn't there yet.

  7. #17
    Join Date
    Jan 2014
    Posts
    240

    Default

    Quote Originally Posted by liam View Post
    Those l4 kernels are pretty impressive. These are what we need for IoT, along with rewritten userspace in "safe language" (for some value of safe). The BIG job will be rewriting drivers (at least certain drivers for devices like network adaptors (including Bluetooth)) so as to make the system as reliable as possible.
    The Genode framework is almost perfect for this sort of project but its security isn't there yet.
    Sorry but no. I think for IoT we need security enhanced Linux + lightweight x86 hardware. Imagine a < 1W TDP and power of fastest Celerons. Possible in few years. I don't get this obsession with micro kernels. GNU Hurd basically showed that micro kernels fail hard and they're not usable for real world. Besides, there's no driver code for these. Even BSD is better.

  8. #18
    Join Date
    Feb 2012
    Location
    Kingston, Jamaica
    Posts
    316

    Default

    Quote Originally Posted by caligula View Post
    Sorry but no. I think for IoT we need security enhanced Linux + lightweight x86 hardware. Imagine a < 1W TDP and power of fastest Celerons. Possible in few years. I don't get this obsession with micro kernels. GNU Hurd basically showed that micro kernels fail hard and they're not usable for real world. Besides, there's no driver code for these. Even BSD is better.
    You don't seem to know what you are talking about.

  9. #19
    Join Date
    Apr 2010
    Posts
    797

    Default

    Quote Originally Posted by caligula View Post
    I don't get this obsession with micro kernels. GNU Hurd basically showed that micro kernels fail hard and they're not usable for real world.
    It's that "theory vs practice" thing again. A proper micro-kernel is a thing of beauty from an architecture perspective - but keeping that purity of architecture means you can't make the compromises and shortcuts that are needed to achieve adequate performance. Monoliths have their own problems, of course, but by not enforcing strict interfaces between modules, they can avoid an awful lot of overhead...

  10. #20
    Join Date
    Feb 2013
    Posts
    51

    Default

    Quote Originally Posted by Delgarde View Post
    It's that "theory vs practice" thing again.
    not really - or better, the kernel world is not that "black or white" anymore
    plus, the OP referred to HURD as a general proof of failure for microkernels in general - but if anything, HURD only proved that stallman and his minions arent able to successfully develop a microkernel based OS and make it mainstream (with the model they're still adhering to, being tied to early 90's microkernel technology because of them not knowing any better)
    but other microkernels have built upon the mistakes and inefficiencies of legacy Mach, distanced themselves a lot from it and strived quite a bit, although in specific niches (rt critical systems typically run on microkernels rather than linux) wouldn exactly call it a failure though..
    A proper micro-kernel is a thing of beauty from an architecture perspective -
    maybe, if you just look at the kernel alone and equate beauty with minimalism.. from an engineering perspective things get quite less rosy when you consider that code that would otherwise belong to the kernel ("drivers", resource arbitration facilities and so on (*)) is still there, together with more (kernel - and user -) non trivial code needed to support the former in running in its own process, be restartable etc
    so the overall view on the OS core (what needs to be present at very least to allow a process to run- which now includes much more than just the kernel) may even be less clean than before

    (*) resource (cpu cycles, memory, files or storage devices, io ports) sharing and arbitration need to be done anyway - but centralising "drivers" and the rest of it in the kernel allows to implement it in an efficient way that also allows the kernel to be sufficient (load the kernel and you're ready to run non core processes - not so with microkernels)
    that's why it's put it beneath the kernel to userpace barrier in a pragmatic, rather than elegant, design ..
    but keeping that purity of architecture means you can't make the compromises and shortcuts that are needed to achieve adequate performance.
    otoh, it's to be noted that microkernels existed that achieved better performance than certain monolithic ones.. fanboyisms apart, it's all a matter of algorithms really, and how much processing a system call takes compared to the overhead of the client server round trip overhad
    consider that during time, microkernels have tacked and sometimes very cleverly solved the ipc overhead problem - something linux has yet to discover as a problem, much less solve (KDBUS still does copy across address spaces and marshaling/demarshaling whereas other systems directly share argument stacks)
    Monoliths have their own problems, of course, but by not enforcing strict interfaces between modules, they can avoid an awful lot of overhead...
    and otoh, dont assume that just because linux isnt, no other monolithic/hybrid kernel is or can be internally compartmentalized with well defined api's...
    Last edited by silix; 07-30-2014 at 11:42 AM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •