From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6925 Path: news.gmane.org!not-for-mail From: stephen Turner Newsgroups: gmane.linux.toybox,gmane.linux.lib.musl.general Subject: Re: [musl] kernel design Date: Wed, 28 Jan 2015 18:27:12 -0500 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0666545215==" X-Trace: ger.gmane.org 1422487641 19871 80.91.229.3 (28 Jan 2015 23:27:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 28 Jan 2015 23:27:21 +0000 (UTC) To: musl-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8@public.gmane.org, toybox-oU9gvf+ajcRUPo+8YfT7LV6hYfS7NtTn@public.gmane.org, "aboriginal-oU9gvf+ajcRUPo+8YfT7LV6hYfS7NtTn@public.gmane.org" Original-X-From: toybox-bounces-oU9gvf+ajcRUPo+8YfT7LV6hYfS7NtTn@public.gmane.org Thu Jan 29 00:27:20 2015 Return-path: Envelope-to: glt-toybox@m.gmane.org Original-Received: from che.dreamhost.com ([66.33.216.23]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YGc0y-0000D1-Tq for glt-toybox@m.gmane.org; Thu, 29 Jan 2015 00:27:17 +0100 Original-Received: from che.dreamhost.com (localhost [127.0.0.1]) by che.dreamhost.com (Postfix) with ESMTP id 03DD91051C; Wed, 28 Jan 2015 15:27:15 -0800 (PST) Original-Received: from mail-yk0-f171.google.com (mail-yk0-f171.google.com [209.85.160.171]) by che.dreamhost.com (Postfix) with ESMTP id 43AC810455; Wed, 28 Jan 2015 15:27:13 -0800 (PST) Original-Received: by mail-yk0-f171.google.com with SMTP id 10so10651950ykt.2; Wed, 28 Jan 2015 15:27:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=sVsfbMS058+d8DUIeUbsxHi2GlzXWxvmpfLWtI7+PfI=; b=nG82+zMJzNljT8BSqN/TzioOAZBd63lk1QzqNpwIfyqt2Q4Z1QYt58+AVQGkQu/c3p gxtnApEYHvEXtEtptnAZqQPwhE7lP3NexkHnYDabrfc8dAjCNi3BYcZ2hblWdeypM4MG K7VM9b67AWUtTOucxrq2RppxnM15S7jEr2cmxVPLnX7w0SuXxQuiMgTz3btTBQSUSeBP jcZtUnYd8NTYpc7UfbajaK+v/QN1y6x+K5hpgMhbJ+j1WSo9eTPvuOsyQVWNGIu93KbI hFargto02mezFj99k6VIkK9hGKTNzAJosAqhzKf27Eej3hDmURjsZyf1yOHqP45CUgCD NR2g== X-Received: by 10.170.206.68 with SMTP id x65mr2329791yke.104.1422487632660; Wed, 28 Jan 2015 15:27:12 -0800 (PST) Original-Received: by 10.170.214.137 with HTTP; Wed, 28 Jan 2015 15:27:12 -0800 (PST) In-Reply-To: X-BeenThere: toybox-oU9gvf+ajcRUPo+8YfT7LV6hYfS7NtTn@public.gmane.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: All-in-one linux command line utility package List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: toybox-bounces-oU9gvf+ajcRUPo+8YfT7LV6hYfS7NtTn@public.gmane.org Original-Sender: "Toybox" Xref: news.gmane.org gmane.linux.toybox:1900 gmane.linux.lib.musl.general:6925 Archived-At: --===============0666545215== Content-Type: multipart/alternative; boundary=001a1139cd800ace7f050dbeb650 --001a1139cd800ace7f050dbeb650 Content-Type: text/plain; charset=UTF-8 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 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 >> 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" >>> 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 >> > > --001a1139cd800ace7f050dbeb650 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Im not confident any one kernel type i have found is bette= r 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.=C2=A0 But ove= r time #@$% gets bloated and I/O stacks dont get updated for new tech etc a= nd everything slows to a crawl.

I dunno, thats just my o= pinion 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&g= t; wrote:
Rich an= d Rob,=C2=A0
Have you seen the new flash ram technology coming out? SSD= strapped to a ram bus and its fast.


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 bot= tleneck to work with. According to this it takes linux 20k instructions to = perform a simple I/O request. =C2=A0

The more i re= ad about the exo kernel stuff the more it seemed like all you needed was th= e exo kernel and a lib to compensate for the missing kernel bits which i wo= nder if it could be mostly a pass through with the kernel not babysitting a= nymore.

exciting times.

stephen

=
On Wed, Jan 28, 2015 at 12:12 PM, stephen Turner= <stephen.n.turner-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
<= div class=3D"gmail_quote">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 'unik= ernel' design such as ellcc bare metal project except that unikernels i= ncludes the api within the kernel (as I understand). IMO the best would a s= ingle address space but would require a language that could guarantee safet= y, you would still need to the split though to verify that it isn't som= ething that shouldn't be loaded though. Correct me if I'm wrong.

On Jan 28, 2015 7:41 AM, "stephen Turner&qu= ot; <ste= phen.n.turner-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
so I have found 4 kernel types, exo, mono, mach, hybr= id.

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 e= verything for it. since i have no programming knowledge im just curious wha= t you guys think about it if you have given it any thought.

<= /div>
It is definately the ideal for hypervisors and with what little i= have read thus far feels like it manages hardware usage like containers bu= t without most of the kernel overhead to do so.=C2=A0

<= div>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 projec= t (is it elk?) is a unikernel + Musl + what ever linkage (syscalls and api?= ) is needed to support native linux apps?

If i am unders= tanding this still out of my element programming jargon, exo kernels don= 9;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 w= ere 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 kerne= ls) of sorts to intermediate for old school apps while allowing new built f= or exo kernel apps to do their unencumbered duties.=C2=A0

sound like wayland + xwayland to anyone else? :-p

Stephen


--001a1139cd800ace7f050dbeb650-- --===============0666545215== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Toybox mailing list Toybox-oU9gvf+ajcRUPo+8YfT7LV6hYfS7NtTn@public.gmane.org http://lists.landley.net/listinfo.cgi/toybox-landley.net --===============0666545215==--