Re: Broken dream of mine :(

[Michal Suchanek]

2009/9/16 Bas Wijnen <address@hidden>:
> 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.

That's true but for my desktop I need Firefox (or equivalent), half
dozen viewers, and unicode xterm.

That should not be too hard to port.

>
>> 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

I could not find much details about this device, not even a shop that
sells them.
I guess I could with deeper digging but fast search only gives sites
that offer mods for the original linux distribution.

> 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 am not impressed with the NanoNote hardware and they do not even say
how much the device will cost. They offer the designs for download
(haven't tried looking at them) but getting a single device
manufactured is very impractical, especially when it includes custom
plastic parts and mechanics (ie keyboard, case).

>
> 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'm not particularly concerned about architecture. I have been running
amd64 for some time which gives some feeling of a non-standard arch -
binaries usually need emulation to run.

Compiling firefox is not nice, though.

>
>> >> 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. :-)


>
>> 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.

This is the basic situation which allows giving certain amount of
memory to each process and ensure it does not take more.

However, if the process has access to a system service or a driver it
might use system resources through this service. To prevent this the
system services should act as an extension to the kernel and require
any process to pay for any services they provide.

So the process should be able to enter a contract with the (system)
service in which it lends part of its resources to the service but
retains the right to relinquish them when the service is performed or
it is no longer interested in the service.

This is where the "drm memory" was used in the EROS/Coyotos design:
the process gives a piece of memory to the service in exchange for a
revoke capability (guaranteed by the kernel) that does not allow
access to the resources lent this way but allows getting back
equivalent amount of blank memory (and cpu time slice). If the service
in question is a media player you can get drm this way.

It is impractical to allow access to this lent memory because it may
be used (besides user filled buffer) for structures internal to the
service which should not be writable to preserve consistency of the
service and should not be readable to prevent needlessly creating
communication channels between different users of the service.

Even in this model writing services such that the user memory can be
revoked without impact on the service is somewhat problematic. Other
systems do not guarantee revocation and require administrator
intervention in case a service keeps resources in possession
indefinitely.

Is this somehow solved in your system?

Thanks

Michal