On Thu, Sep 17, 2009 at 04:20:16PM +0200, Michal Suchanek wrote: > > 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.
You may be right. For Iris, once it is running decently, I shall likely port it to x86 anyway, and it will have a POSIX library, so things which don't need special drivers should just work (after compiling). For development I am more interested in exotic hardware, also because people who use it are more likely to try such an exotic kernel. :-) > > 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. http://www.trendtac.nl is the importer's "support" site for it in the Netherlands. They can be bought here at Mediamarkt and Intertoys, but I heard that they are hard to get by in other countries. If you don't intend to hack on them yourself, I wouldn't advise you to buy one anyway. > > 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 The current version, which will release in or before november, has very limited hardware indeed. It is presented as a starting point, which will be expanded on. For the next version, there will at least be USB host support. That would already make it much more useful IMO. There are many more ideas; not all of them can be implemented, so they'll make some choices. For this version of the device the same thing is true: it is only usable for people who want to hack on it; it's not something a shop with finished devices would sell. > and they do not even say how much the device will cost. I think they don't know yet. ;-) > 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). Of course. This is just one point where they show how open they are, and that is not of much value to everyone. But I know it would be very nice to have schematics and chip numbers for some devices: it would save a lot of work figuring out how to drive them. > 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. For the user, having a non-standard architecture doesn't mean much, especially if you use free software everywhere, so you never need to run non-native binaries. For writing device drivers (and kernels), things are of course different. There too, it doesn't make too much difference, but when it does (the assembly parts), I still see that x86 is a lousy architecture. > This is the basic situation which allows giving certain amount of > memory to each process and ensure it does not take more. Yes. Most systems have something like this, or at least try. > However, if the process has access to a system service or a driver it > might use system resources through this service. Exactly. That is something which is not solved by Linux, for example. > 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. Right. > 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. ... > 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? Yes, IMO it is, but judge for yourself. The problem on Coyotos in fact comes from constructors, which don't exist on my system. Here's why this creates the problem: Without constructors, every process has a parent. That parent provides it with everything it needs to start: memory, its initial code, and its capabilities. This means that a child can never do anything that the parent could not have done itself. It also means that a child must always trust its parent. It is not trivial that this is a good thing, but I think it is (you have probably seen the discussion on this list about it). The Basic process layout is as follows: root of memories + driver 1 + driver 2 + other system service + user 1 session manager -- application from user 1 -- other application from user 1 --- plugin for application + user 2 session manager -- application from user 2 etc. Here + means it's a system-trusted process, which the users cannot debug. - means a process untrusted by the system (but they may be trusted by others, for example the plugin trusts its parent application). First, let's see about rogue drivers (which don't return resources, for example). If its about a system driver, you are in big trouble. Not returning resources is not a problem now: a critical part of the system is misbehaving, meaning the entire system is no longer stable. This is something that should not happen, and there is no point to try to defend against it. The other option is a driver which is run by the user. For example, I can run my own filesystem and let a process use that. Would it be acceptable if the process must trust the driver that it will not "steal" its memory? I think it is. The process isn't the one with the problem in that case; the user is. And the user is still capable of killing the driver, because it's just another process under the user's control. Further, the user's session is a trusted program, which will behave properly. So if a program wants to provide "opaque" memory to a system driver, it will do this by telling its session to give that driver some memory. The system driver trusts the session, the session trusts the driver, and all is well. If possible I will try to avoid this scenario, but I don't have a problem to use it when needed. If a program wants to provide "opaque" memory to an unstrusted driver, it also asks its session. Its session sends memory to the driver, but does allow its owner (that's the user, not the requesting process) to debug it (that's different with the system driver case). This means the user will remain in control. This also means that it is impossible for a user to give undebuggable opaque memory to a driver which is owned by a different user. This is intentional. It would be trivial to implement it (it will effectively already be done for the system drivers), but I don't want that. This is a social choice, based on a discussion on this list which I think you followed (your question seems to be based on it). Note that all this is based on things which are not yet implemented, so it may still change. Does this answer your question? Thanks, Bas
signature.asc
Description: Digital signature
