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
