From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6906 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 12:12:24 -0500 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0365230678==" X-Trace: ger.gmane.org 1422465156 23395 80.91.229.3 (28 Jan 2015 17:12:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 28 Jan 2015 17:12:36 +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 Wed Jan 28 18:12:35 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 1YGWAI-0002cz-R6 for glt-toybox@m.gmane.org; Wed, 28 Jan 2015 18:12:31 +0100 Original-Received: from che.dreamhost.com (localhost [127.0.0.1]) by che.dreamhost.com (Postfix) with ESMTP id DF8F310205; Wed, 28 Jan 2015 09:12:28 -0800 (PST) Original-Received: from mail-yh0-f42.google.com (mail-yh0-f42.google.com [209.85.213.42]) by che.dreamhost.com (Postfix) with ESMTP id 38513100F0; Wed, 28 Jan 2015 09:12:27 -0800 (PST) Original-Received: by mail-yh0-f42.google.com with SMTP id a41so9281491yho.1; Wed, 28 Jan 2015 09:12:25 -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=C2kqRp2eAt58dSIrcwy4XYQS8kDs0IGyeft9KjNCGTI=; b=WEafy/Jg/U2DYEIEh1AXvupjO0GxfSRxDCZMyAizTd8gWGKrWkwP0srs6vh+p0Ssw1 LvmRoEOw+CaGbM7+GQyb8i6H4IVKVNE3/NvbXlgpG+3k/EEntsvOSNjZoDyJSkWgeYBN mEvqM3qHuIaxfv5UFHLxDHidCRG48nOfe0QTAN++el5dUDDzHlesQL0MqL/10evdacLh JacekXU+aiRYRlKHQ/y6Ww0ySHGNDiPsGq4IFGr4vuMgWnGDXim3JpG7KY3jXooWPvxE gHJdzwHHBEU49F4mgM2Q9w2Jfwh5n8kC4a+/48RBDTIsuaexXbUyhkW3YkL+1LZI6DyY 3kmA== X-Received: by 10.236.23.132 with SMTP id v4mr1709693yhv.160.1422465144750; Wed, 28 Jan 2015 09:12:24 -0800 (PST) Original-Received: by 10.170.214.137 with HTTP; Wed, 28 Jan 2015 09:12:24 -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:1894 gmane.linux.lib.musl.general:6906 Archived-At: --===============0365230678== Content-Type: multipart/alternative; boundary=089e013a011aa88710050db9791f --089e013a011aa88710050db9791f Content-Type: text/plain; charset=UTF-8 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 --089e013a011aa88710050db9791f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 28, 2015 at 11:19 AM, Nathan McSween <nwmcsween-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org&g= t; wrote:

An exokernel just multi= plexes resources, similar concept to 'unikernel' design such as ell= cc bare metal project except that unikernels includes the api within the ke= rnel (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 th= e 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&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

Unikern= els 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 t= he apps they take a step back and simply supervise. this leaves the existin= g 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 kerne= l apps to do their unencumbered duties.=C2=A0

soun= d like wayland + xwayland to anyone else? :-p

Step= hen
--089e013a011aa88710050db9791f-- --===============0365230678== 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 --===============0365230678==--