Re: [musl] kernel design

[stephen Turner <stephen.n.turner-Re5JQEeQqe8AvxtiuMwx3w@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