* kernel design @ 2015-01-28 15:41 stephen Turner 2015-01-28 16:19 ` Nathan McSween 0 siblings, 1 reply; 7+ messages in thread From: stephen Turner @ 2015-01-28 15:41 UTC (permalink / raw) To: toybox-oU9gvf+ajcRUPo+8YfT7LV6hYfS7NtTn, musl-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8 [-- Attachment #1.1: Type: text/plain, Size: 594 bytes --] so I have found 4 kernel types, exo, mono, mach, hybrid. the Exo sounds like the way to go but im curious if it could be built to work with the existing linux world without rewriting everything for it. since i have no programming knowledge im just curious what you guys think about it if you have given it any thought. It is definately the ideal for hypervisors and with what little i have read thus far feels like it manages hardware usage like containers but without most of the kernel overhead to do so. Im getting tickled about this exo kernel. think i will go find more on it. stephen [-- Attachment #1.2: Type: text/html, Size: 714 bytes --] [-- Attachment #2: Type: text/plain, Size: 182 bytes --] _______________________________________________ Toybox mailing list Toybox-oU9gvf+ajcRUPo+8YfT7LV6hYfS7NtTn@public.gmane.org http://lists.landley.net/listinfo.cgi/toybox-landley.net ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: kernel design 2015-01-28 15:41 kernel design stephen Turner @ 2015-01-28 16:19 ` Nathan McSween [not found] ` <CAMSMCx=rCLiH2Yp6LHNEkosfG_ccx+o+sZHYq23uoCTEpeBEvw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 7+ messages in thread From: Nathan McSween @ 2015-01-28 16:19 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 1121 bytes --] An exokernel just multiplexes resources, similar concept to 'unikernel' design such as ellcc bare metal project except that unikernels includes the api within the kernel (as I understand). IMO the best would a single address space but would require a language that could guarantee safety, you would still need to the split though to verify that it isn't something that shouldn't be loaded though. Correct me if I'm wrong. On Jan 28, 2015 7:41 AM, "stephen Turner" <stephen.n.turner@gmail.com> wrote: > so I have found 4 kernel types, exo, mono, mach, hybrid. > > the Exo sounds like the way to go but im curious if it could be built to > work with the existing linux world without rewriting everything for it. > since i have no programming knowledge im just curious what you guys think > about it if you have given it any thought. > > It is definately the ideal for hypervisors and with what little i have > read thus far feels like it manages hardware usage like containers but > without most of the kernel overhead to do so. > > Im getting tickled about this exo kernel. think i will go find more on it. > > stephen > [-- Attachment #2: Type: text/html, Size: 1487 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <CAMSMCx=rCLiH2Yp6LHNEkosfG_ccx+o+sZHYq23uoCTEpeBEvw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [musl] kernel design [not found] ` <CAMSMCx=rCLiH2Yp6LHNEkosfG_ccx+o+sZHYq23uoCTEpeBEvw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2015-01-28 17:12 ` stephen Turner [not found] ` <CAA7aPHikdoO3vpVqkXA6_LLvzdEBHMSHZhRtU3LH7+LYfsa9Ug-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2015-01-28 23:25 ` Justin Cormack 0 siblings, 2 replies; 7+ messages in thread From: stephen Turner @ 2015-01-28 17:12 UTC (permalink / raw) To: musl-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8, toybox-oU9gvf+ajcRUPo+8YfT7LV6hYfS7NtTn, aboriginal-oU9gvf+ajcRUPo+8YfT7LV6hYfS7NtTn@public.gmane.org [-- Attachment #1.1: Type: text/plain, Size: 2054 bytes --] On Wed, Jan 28, 2015 at 11:19 AM, Nathan McSween <nwmcsween-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > An exokernel just multiplexes resources, similar concept to 'unikernel' > design such as ellcc bare metal project except that unikernels includes the > api within the kernel (as I understand). IMO the best would a single > address space but would require a language that could guarantee safety, you > would still need to the split though to verify that it isn't something that > shouldn't be loaded though. Correct me if I'm wrong. > On Jan 28, 2015 7:41 AM, "stephen Turner" <stephen.n.turner-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > wrote: > >> so I have found 4 kernel types, exo, mono, mach, hybrid. >> >> the Exo sounds like the way to go but im curious if it could be built to >> work with the existing linux world without rewriting everything for it. >> since i have no programming knowledge im just curious what you guys think >> about it if you have given it any thought. >> >> It is definately the ideal for hypervisors and with what little i have >> read thus far feels like it manages hardware usage like containers but >> without most of the kernel overhead to do so. >> >> Im getting tickled about this exo kernel. think i will go find more on it. >> >> stephen >> > Unikernels is that bare metal stuff is it not? so then that elk project (is it elk?) is a unikernel + Musl + what ever linkage (syscalls and api?) is needed to support native linux apps? If i am understanding this still out of my element programming jargon, exo kernels don't manage the apps they take a step back and simply supervise. this leaves the existing gnu applications to speak directly with hardware which they were not made for by using syscalls that the existing kernel recognizes. so there would need to be a userspace kernel (now were getting into mach kernels) of sorts to intermediate for old school apps while allowing new built for exo kernel apps to do their unencumbered duties. sound like wayland + xwayland to anyone else? :-p Stephen [-- Attachment #1.2: Type: text/html, Size: 3026 bytes --] [-- Attachment #2: Type: text/plain, Size: 182 bytes --] _______________________________________________ Toybox mailing list Toybox-oU9gvf+ajcRUPo+8YfT7LV6hYfS7NtTn@public.gmane.org http://lists.landley.net/listinfo.cgi/toybox-landley.net ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <CAA7aPHikdoO3vpVqkXA6_LLvzdEBHMSHZhRtU3LH7+LYfsa9Ug-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [musl] kernel design [not found] ` <CAA7aPHikdoO3vpVqkXA6_LLvzdEBHMSHZhRtU3LH7+LYfsa9Ug-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2015-01-28 21:41 ` stephen Turner [not found] ` <CAA7aPHiXNV-naEGyxtO=hrrZ2W_2_rwOz4Vmou8ZROksCuAqaQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 7+ messages in thread From: stephen Turner @ 2015-01-28 21:41 UTC (permalink / raw) To: musl-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8, toybox-oU9gvf+ajcRUPo+8YfT7LV6hYfS7NtTn, aboriginal-oU9gvf+ajcRUPo+8YfT7LV6hYfS7NtTn@public.gmane.org [-- Attachment #1.1: Type: text/plain, Size: 3008 bytes --] Rich and Rob, Have you seen the new flash ram technology coming out? SSD strapped to a ram bus and its fast. http://highscalability.com/blog/2012/1/19/is-it-time-to-get-rid-of-the-linux-os-model-in-the-cloud.html Rich, since you tweeted about kernel stuff this is a good thing to keep in mind if your still looking at it. The I/O of devices is changing and apparently linux is still a huge bottleneck to work with. According to this it takes linux 20k instructions to perform a simple I/O request. The more i read about the exo kernel stuff the more it seemed like all you needed was the exo kernel and a lib to compensate for the missing kernel bits which i wonder if it could be mostly a pass through with the kernel not babysitting anymore. exciting times. stephen On Wed, Jan 28, 2015 at 12:12 PM, stephen Turner <stephen.n.turner-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > wrote: > On Wed, Jan 28, 2015 at 11:19 AM, Nathan McSween <nwmcsween-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > wrote: > >> An exokernel just multiplexes resources, similar concept to 'unikernel' >> design such as ellcc bare metal project except that unikernels includes the >> api within the kernel (as I understand). IMO the best would a single >> address space but would require a language that could guarantee safety, you >> would still need to the split though to verify that it isn't something that >> shouldn't be loaded though. Correct me if I'm wrong. >> On Jan 28, 2015 7:41 AM, "stephen Turner" <stephen.n.turner-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> >> wrote: >> >>> so I have found 4 kernel types, exo, mono, mach, hybrid. >>> >>> the Exo sounds like the way to go but im curious if it could be built to >>> work with the existing linux world without rewriting everything for it. >>> since i have no programming knowledge im just curious what you guys think >>> about it if you have given it any thought. >>> >>> It is definately the ideal for hypervisors and with what little i have >>> read thus far feels like it manages hardware usage like containers but >>> without most of the kernel overhead to do so. >>> >>> Im getting tickled about this exo kernel. think i will go find more on >>> it. >>> >>> stephen >>> >> > Unikernels is that bare metal stuff is it not? so then that elk project > (is it elk?) is a unikernel + Musl + what ever linkage (syscalls and api?) > is needed to support native linux apps? > > If i am understanding this still out of my element programming jargon, exo > kernels don't manage the apps they take a step back and simply supervise. > this leaves the existing gnu applications to speak directly with hardware > which they were not made for by using syscalls that the existing kernel > recognizes. so there would need to be a userspace kernel (now were getting > into mach kernels) of sorts to intermediate for old school apps while > allowing new built for exo kernel apps to do their unencumbered duties. > > sound like wayland + xwayland to anyone else? :-p > > Stephen > [-- Attachment #1.2: Type: text/html, Size: 4585 bytes --] [-- Attachment #2: Type: text/plain, Size: 182 bytes --] _______________________________________________ Toybox mailing list Toybox-oU9gvf+ajcRUPo+8YfT7LV6hYfS7NtTn@public.gmane.org http://lists.landley.net/listinfo.cgi/toybox-landley.net ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <CAA7aPHiXNV-naEGyxtO=hrrZ2W_2_rwOz4Vmou8ZROksCuAqaQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [musl] kernel design [not found] ` <CAA7aPHiXNV-naEGyxtO=hrrZ2W_2_rwOz4Vmou8ZROksCuAqaQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2015-01-28 23:27 ` stephen Turner [not found] ` <CAA7aPHiYeFpvYMtZ_M=2+nFBKQ9v480RSKRa9DdVLd_RTC5bmQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 7+ messages in thread From: stephen Turner @ 2015-01-28 23:27 UTC (permalink / raw) To: musl-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8, toybox-oU9gvf+ajcRUPo+8YfT7LV6hYfS7NtTn, aboriginal-oU9gvf+ajcRUPo+8YfT7LV6hYfS7NtTn@public.gmane.org [-- Attachment #1.1: Type: text/plain, Size: 3617 bytes --] Im not confident any one kernel type i have found is better than the other really. To me it seems like small simple and to the point always wins. musl, toybox, these micro kernels all have that. But over time #@$% gets bloated and I/O stacks dont get updated for new tech etc and everything slows to a crawl. I dunno, thats just my opinion at the moment. Its also my opinion i had too much coffee. On Wed, Jan 28, 2015 at 4:41 PM, stephen Turner <stephen.n.turner-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > Rich and Rob, > Have you seen the new flash ram technology coming out? SSD strapped to a > ram bus and its fast. > > > http://highscalability.com/blog/2012/1/19/is-it-time-to-get-rid-of-the-linux-os-model-in-the-cloud.html > > Rich, since you tweeted about kernel stuff this is a good thing to keep in > mind if your still looking at it. The I/O of devices is changing and > apparently linux is still a huge bottleneck to work with. According to this > it takes linux 20k instructions to perform a simple I/O request. > > The more i read about the exo kernel stuff the more it seemed like all you > needed was the exo kernel and a lib to compensate for the missing kernel > bits which i wonder if it could be mostly a pass through with the kernel > not babysitting anymore. > > exciting times. > > stephen > > On Wed, Jan 28, 2015 at 12:12 PM, stephen Turner < > stephen.n.turner-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > >> On Wed, Jan 28, 2015 at 11:19 AM, Nathan McSween <nwmcsween-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> >> wrote: >> >>> An exokernel just multiplexes resources, similar concept to 'unikernel' >>> design such as ellcc bare metal project except that unikernels includes the >>> api within the kernel (as I understand). IMO the best would a single >>> address space but would require a language that could guarantee safety, you >>> would still need to the split though to verify that it isn't something that >>> shouldn't be loaded though. Correct me if I'm wrong. >>> On Jan 28, 2015 7:41 AM, "stephen Turner" <stephen.n.turner-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> >>> wrote: >>> >>>> so I have found 4 kernel types, exo, mono, mach, hybrid. >>>> >>>> the Exo sounds like the way to go but im curious if it could be built >>>> to work with the existing linux world without rewriting everything for it. >>>> since i have no programming knowledge im just curious what you guys think >>>> about it if you have given it any thought. >>>> >>>> It is definately the ideal for hypervisors and with what little i have >>>> read thus far feels like it manages hardware usage like containers but >>>> without most of the kernel overhead to do so. >>>> >>>> Im getting tickled about this exo kernel. think i will go find more on >>>> it. >>>> >>>> stephen >>>> >>> >> Unikernels is that bare metal stuff is it not? so then that elk project >> (is it elk?) is a unikernel + Musl + what ever linkage (syscalls and api?) >> is needed to support native linux apps? >> >> If i am understanding this still out of my element programming jargon, >> exo kernels don't manage the apps they take a step back and simply >> supervise. this leaves the existing gnu applications to speak directly with >> hardware which they were not made for by using syscalls that the existing >> kernel recognizes. so there would need to be a userspace kernel (now were >> getting into mach kernels) of sorts to intermediate for old school apps >> while allowing new built for exo kernel apps to do their unencumbered >> duties. >> >> sound like wayland + xwayland to anyone else? :-p >> >> Stephen >> > > [-- Attachment #1.2: Type: text/html, Size: 5552 bytes --] [-- Attachment #2: Type: text/plain, Size: 182 bytes --] _______________________________________________ Toybox mailing list Toybox-oU9gvf+ajcRUPo+8YfT7LV6hYfS7NtTn@public.gmane.org http://lists.landley.net/listinfo.cgi/toybox-landley.net ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <CAA7aPHiYeFpvYMtZ_M=2+nFBKQ9v480RSKRa9DdVLd_RTC5bmQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [musl] kernel design [not found] ` <CAA7aPHiYeFpvYMtZ_M=2+nFBKQ9v480RSKRa9DdVLd_RTC5bmQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2015-01-30 7:54 ` Bastian Bittorf 0 siblings, 0 replies; 7+ messages in thread From: Bastian Bittorf @ 2015-01-30 7:54 UTC (permalink / raw) To: stephen Turner Cc: aboriginal-oU9gvf+ajcRUPo+8YfT7LV6hYfS7NtTn@public.gmane.org, musl-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8, toybox-oU9gvf+ajcRUPo+8YfT7LV6hYfS7NtTn * stephen Turner <stephen.n.turner-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [29.01.2015 20:06]: > Im not confident any one kernel type i have found is better than the other [...] please stop fullquoting and read https://www.netmeister.org/news/learn2quote.html bye, bastian ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: kernel design 2015-01-28 17:12 ` [musl] " stephen Turner [not found] ` <CAA7aPHikdoO3vpVqkXA6_LLvzdEBHMSHZhRtU3LH7+LYfsa9Ug-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2015-01-28 23:25 ` Justin Cormack 1 sibling, 0 replies; 7+ messages in thread From: Justin Cormack @ 2015-01-28 23:25 UTC (permalink / raw) To: musl; +Cc: toybox, aboriginal@lists.landley.net On 28 January 2015 at 17:12, stephen Turner <stephen.n.turner@gmail.com> wrote: > On Wed, Jan 28, 2015 at 11:19 AM, Nathan McSween <nwmcsween@gmail.com> > wrote: > Unikernels is that bare metal stuff is it not? so then that elk project (is > it elk?) is a unikernel + Musl + what ever linkage (syscalls and api?) is > needed to support native linux apps? > > If i am understanding this still out of my element programming jargon, exo > kernels don't manage the apps they take a step back and simply supervise. > this leaves the existing gnu applications to speak directly with hardware > which they were not made for by using syscalls that the existing kernel > recognizes. so there would need to be a userspace kernel (now were getting > into mach kernels) of sorts to intermediate for old school apps while > allowing new built for exo kernel apps to do their unencumbered duties. I am not sure the terms are defined that well - every project seems to define a term for its architecture, have never seen two using the same term. Some provide traditional Posix APIs, while some like Mirage are language specific with custom interfaces. Then you can run them on bare metal, or Xen (which ships with a stub interface which makes it easier). I work on the NetBSD rump kernel (rumpkernel.org) which is a slightly different architecture again. Justin ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-01-30 7:54 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-01-28 15:41 kernel design stephen Turner 2015-01-28 16:19 ` Nathan McSween [not found] ` <CAMSMCx=rCLiH2Yp6LHNEkosfG_ccx+o+sZHYq23uoCTEpeBEvw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2015-01-28 17:12 ` [musl] " stephen Turner [not found] ` <CAA7aPHikdoO3vpVqkXA6_LLvzdEBHMSHZhRtU3LH7+LYfsa9Ug-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2015-01-28 21:41 ` stephen Turner [not found] ` <CAA7aPHiXNV-naEGyxtO=hrrZ2W_2_rwOz4Vmou8ZROksCuAqaQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2015-01-28 23:27 ` stephen Turner [not found] ` <CAA7aPHiYeFpvYMtZ_M=2+nFBKQ9v480RSKRa9DdVLd_RTC5bmQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2015-01-30 7:54 ` Bastian Bittorf 2015-01-28 23:25 ` Justin Cormack
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).