Re: Broken dream of mine :(

[Bas Wijnen]

On Wed, Sep 16, 2009 at 11:18:07AM +0200, Michal Suchanek wrote:
> > However, I currently prefer to focus on Iris, because with her target
> > hardware, it is more likely that people will actually want to use it.  I
> > don't see any way to get people to change their desktop system.  After
> > all, a new system will for quite some time have problems such as missing
> > drivers.
> 
> I would rather work on system that runs on x86 because it's easier to
> find hardware for testing once the system can run.

This is true, but even I would mostly run such a kernel in qemu, so I
can't expect others to "really" use it either.

Also, even if it's a suitable kernel for a desktop, that doesn't
magically create an entire desktop system on top of it. ;-)  With my
demands, the GNU system would need a lot of work before it would be
acceptable as well, so simply "supporting POSIX" doesn't really do what
I want either.

> However, I think I can get at some arm based access points or a SGI O2
> easily (iirc you said the target is arm and mips) so this is not that
> much of a problem, especially similar access points should be easy to
> get anywhere.

No, the current targets are two very specific devices, the mini-pc that
is called Trendtac here (and has many other names, such as Skytone alpha
400, in other places), and the soon to be released open-hardware
micro-pc (currently more of a PDA, actually) called Ben NanoNote.  Both
use a mips processor.  Porting to other devices with the same "system on
chip" should be very easy, to other mips devices should be easy, to
other architectures should not be very hard.  However, I'll probably
keep my focus on the NanoNote at the moment, because I really like the
open hardware ideas behind it and want them to succeed. :-)

I was talking about mips and arm as examples of better architectures
than x86.  I'm currently only targeting mips, more specifically
system-on-chip devices from Ingenic Semiconductor.

> >> I was somewhat curious about the results because the kernel was
> >> supposed to have a resource management which was based on ideas that I
> >> could not imagine working.
> >
> > What do you mean by "not working"?

I didn't really see an answer to this, and am interested to know. :-)

> For one startup time is important for desktops and 24/7 services.

Yes, I agree.  I am very much working on this.  For the target devices,
it is not required to have all hardware autodetected every boot.  So I
just set things up at compile time and skip the detection process.  In
the same way I intend to handle daemons, but I'm not exactly sure how
yet, because I haven't implemented enough to have the details clear.  It
might become a persistent system, meaning that shutting down is
identical to suspending.

> CPU performance is important for batch processing

Actually, I think it isn't very important at all.  The speeds go up so
fast, and are at such high level anyway, that the CPU is hardly ever the
bottleneck of an operation.  There are of course some exceptions, but
they are not important to me.  Not that I would waste CPU time when I
get the chance, but it's not worth much when comparing it to security or
user experience, for example.

On the other hand, battery time is important to me, which in many cases
means that CPU time is something to watch anyway.

> but desktops and many other application may be more interested in
> event latency - the time it takes to process a keypress or a packet
> received from the network.

That is indeed an important property.  I have no idea how Iris performs
on it, though.  I have only implemented a trivial scheduler at the
moment, which doesn't use priorities, but I think it is important to use
a method which can reach low latency.

> You should be able to find an application for which the kernel
> performs decently.

That should always work, but it is of course nice if it can be used more
broadly.  Then again, my choice of target hardware is significantly
narrowing down the applications that can perform at all, and I don't
consider that a problem either. ;-)  Not that I want to restrict the
kernel to that hardware, it's just good for me as a starting platform.

There are several reasons I like it; one is that it is not x86, which
just makes it nicer to work with and it scores more geek points. :-P
Another reason is that it is relatively simple hardware for which I can
write good drivers.  On x86, there are just too many vague devices
floating around, which often don't even follow the standards, if they
exist.

> For the kernel to be interesting for me I would want to see something
> different from the other kernels available.

Again I agree with you.  That is also the reason for me to write a new
kernel.  Just doing the same as others, but faster, doesn't give me as
much satisfaction.

> The resource management was supposed to be such thing. From what I
> read on the list I never get a clear idea how that is supposed to work
> and never saw an update on that.
> 
> So is the resource management finished and working somehow? Is it
> documented somewhere?

As a programmer, I have a class penalty on documentation skills. ;-)  I
tried to write some documents (you can check Iris' sources at
http://www.qi-hardware.com under projects), but they aren't finished,
and probably even outdated.  I'll give you a
not-as-short-as-I-initially-expected summary; please ask for
clarification on what you're interested in.

First of all, there are two things that Iris does, which L4 doesn't do:
memory management and scheduling.  For the design it doesn't really
matter, but it may be good to know that the things I'm talking about
here are in the kernel (and I'm still not completely sure if that is a
good idea).

Memory management works with Memory objects.  They are containers of
kernel objects and other memory.  There are a few top-level objects
which don't live in a memory, the only interesting one of which is the
top-level Memory, which contains all other things (directly or
indirectly).

A Memory can contain other Memories, Threads (which contain the state of
a thread which may be running), Pages (which contain frames which can be
mapped into user space, and can be shared), Caps objects (which contain
capabilities), Receivers (which can receive messages from capabilities
that are created on them) and it may hold a mapping table, which is used
by its Threads when they run (in other words, it is also the address
space).

Shared frames (in Pages) can be paid by one or more holders.  When there
is no paying Page, the frame is lost.  When there is more than one
payer, there is a frame on the system which cannot be claimed by anyone
(this is something I want to fix eventually).

Any kernel operation which needs storage must bring that storage with
it.  The kernel never allocates any memory.

A capability to a memory allows the user to create new objects in it.
Each memory has a limit to how much space it can use.  If an operation
would break that limit, or the limit of any of the ancestor Memories, it
fails.  So to give a new process limited memory, for example, it is put
into its own Memory (which is done anyway because it needs an address
space) and the limit on it is set up.

So a thread can never use more memory than it can pay for (or find
others to pay for).  This is true for all operations, because the kernel
doesn't pay for anything.

Cpu time is currently not controlled, because I haven't written a proper
scheduler.  A good policy must certainly be part of it though, which is
why I'm not too happy about having the scheduler in the kernel (I want
to put policy in a place where it can be more easily changed).

Other resources are controlled in two ways.  First, by the capability
protection that the kernel provides: a thread which doesn't own a
capability to a driver is unable to communicate with it, and thus unable
to make use of the resources it controls (this protection also exists
for kernel objects).  The second is in the driver (or other resource
manager).  It may implement a policy on when and how users are allowed
to use operations on it.  There is no kernel support for this, nor is it
needed.

> Or does it work without one? It's certainly possible to run a system
> without one, most popular systems work like that these days.

The main reason I'm writing these kernels is that I like the idea that a
user can trust the computer.  That it is possible to run a program and
see what it does, without any risk that sensitive data is destroyed of
leaked, even if there may be some bugs in some programs (not too many of
course, and not in critical places).  Such a system is impossible
without good resource management, especially without control over
communication channels.

I hope this answers your question.  If not, please ask again, but with
different words. ;-)  I also want to remind you that I had a question
for you near the top of this mail.

Thanks,
Bas

signature.asc
Description: Digital signature