| xscript | ok marcus, so you're advocating for a system fully based on capabilities, and fully exploitaiting it's characteristics :)
| xscript | is the talk (all it's pas time, not future ;)) already posted somewhere? my connection got down for a while...
| bing | how do existing persistent operating systems clean up faulty state?
|
|---|
| @marcus | bing: there are two parts to the answer.
| xscript | EROS checks that no faulty state is saved
|
|---|
| @marcus | 1) Some faulty state is just cleaned up by restarting the affected components.
|
|---|
| @marcus | Ie, just like you know it.
|
|---|
| @marcus | 2) The core of the system,ie the checkpointing mechanism itself, better never fails :)
|
|---|
| @marcus | There are a number of safe guards in place. As xscript says, there are consistency checks.
|
|---|
| @marcus | The system tries hard to never commit a faulty checkpoint.
|
|---|
| @marcus | Of course, it can only do so at a level which semantics it understands
|
|---|
| @marcus | The rest is handled normally.
|
|---|
| @marcus | In practice, rumor has it that for EROS, there has never been a bug in the checkpointing process outside development.
[2005-12-19 14:22:51] | bing | marcus: thanks for the answer :-)
[2005-12-19 14:23:24] | zerog | the reason for so few HURD developers is funds, right? I mean, lets think HURD as a midpoint in the OS/kernel research and look beyond what can HURD give us, why not fund that research?
|
|---|
| @marcus | zerog: I don't think it is just funds.
| xscript | and interest
| xscript | i think
|
|---|
| @marcus | zerog: I have talked to many people, and often I hear that the ideas are interesting, and the goals are sound, but the plan is not convincing.
|
|---|
| @marcus | I think what is lacking is a _convincing_ vision for a better alternative.
| xscript | marcus: what do you mean with the plan?
|
|---|
| @marcus | Ie, people are waiting for some proof.
| zerog | but is like a endless loop... OMG
|
|---|
| @marcus | xscript: specifically, a clear design (roadmap) and a working prototype which already exhibits all the core goals, ie security and performance.
| xscript | so, "show me an already good thing to make me say it could be good"...
|
|---|
| @marcus | The Hurd runs emacs, but it is neither stable, nor secure, nor fast.
| xscript | well, I think that one of the problems is that a truly secure system should be entirely componentized....
|
|---|
| @marcus | We can keep adding more features to the Hurd, but this won't convince people as long as the _core goals_ are not proven.
| xscript | and that means a lot of rewriting
| zerog | so, HURD is more like a turnpoint to elsewhere?
|
|---|
| @marcus | xscript: yes, and there is the larger problem that the over-all performance is not a function of the individual local performances.
|
|---|
| @marcus | zerog: can you rephrase that?
| zerog | okey
| xscript | that points (or should point) to a new paradigm...
| zerog | exactly
| zerog | xscript can you read minds :P
|
|---|
| @marcus | I'm still lost.
| xscript | zerog: yesssss..... wait.... i see.... ui! better keep it secret ;)
|
|---|
| @marcus | You mean if the Hurd is at a turning point?
| zerog | no no no
| xscript | marcus: I think that zerog is talking about what I said about rewriting the way aplication code behaves....
| zerog | more than that
| zerog | if HURD is a turnpoint to go beyond what he can proof by himself
| zerog | to another level of development not a white elephant
|
|---|
| @marcus | well, I would like to think that the basic concepts, if realized, could lead to a new level at the application and human-computer interface as well
|
|---|
| @marcus | is that what you mean?
| zerog | yes
marcus: Do you think that an EROS based Hurd will perform better than Hurd/Mach (knowing about the extra work needed for its security implementation)? If so, how would this be achieved?
|
|---|
| @marcus | clearly we are talking about quite different operating systems from Unix, but let me also stay very clearly:
|
|---|
| @marcus | we take compatibility very seriously.
|
|---|
| @marcus | luckily, it seems that backward compatibility can be achieved not only with reasonable effort, but also with reasonable results
|
|---|
| @marcus | k0ro: well, it's hard to imagine it performing worse :)
|
|---|
| @marcus | but, yes, why do we believe we can do better? that's a good question
|
|---|
| @marcus | there are a couple of reasons
| zerog | if we can only use HURD as a theoretical model without any advantages for development to the next OS/kernel, we are going to nowhere, thats what i mean
|
|---|
| @marcus | first, the IPC mechanism is much better.
[2005-12-19 14:33:21] | xscript | I think eros has proved to have fairly good performance...
|
|---|
| @marcus | Also, the kernel itself is small, which helps to preserve the cache
|
|---|
| @marcus | these are all synergetic properties from the L4 research
|
|---|
| @marcus | we know from the eros design that disk throughput is pretty good on persistent systems, for the persistent store.
|
|---|
| @marcus | however, there is problem here, because with persistent, our answers to self-management of resources may change
|
|---|
| @marcus | so, we have to reconsider our earlier arguments
| zerog | i check and eros is not anymore under development, now is call it capROS, thats why i insist so much in FUNDS
| xscript | no, it's now Coyotos
|
|---|
| @marcus | k0ro: so, we would have to look at different performance aspects separately in this discussion to reduce confusion.
| xscript | zerog: and it's on a development phase
|
|---|
| @marcus | zerog: the successor of eros is coyotos
|
|---|
| @marcus | zerog: well, in the current economic and political climate, funds are very hard to obtain
| zerog | okey, i recheck the link, sorry im recovering from a pre infarct :)
Coyotos is the sucessor of EROS, capROS is the *continuation* of EROS
| zerog | yes i know
marcus: CoyotOS is capabilities based?
|
|---|
| @marcus | jlas9: yes. coyotos is only incrementally different from eros
| zerog | we need to raise funds... anyone join me to break into a bank?
|
|---|
| @marcus | jlas9: the main purpose of coyotos is to create a verifiable model that can be proven by formal verification
|
|---|
| @marcus | but that is not of much concern to us
|
|---|
| @marcus | it's also a clean up of eros
| @riel | why does it need funding? are there not enough people interested in developing the software as a hobby?
| @riel | or maybe as university projects ?
|
|---|
| @marcus | riel: university projects need funding as well
| zerog | yes
| xscript | well, it's of our concern if we sould write code for it :)
marcus: Has EROS/Coyotos/Whatever proved to be usable (in performance terms) in a multiserver environment?
|
|---|
| @marcus | we try to do our best
| zerog | and developer need to pay bills
|
|---|
| @marcus | k0ro: KeyKOS, which is what EROS is based on, has been in production with a multiserver environment
|
|---|
| @marcus | for example, look at the KeyNIX paper to see how they modeled a Unix environment
| zerog | in SMGL a good developer drop, cause he needs money for her family, thats sad.
| xscript | k0ro: in fact, I think that eros descends from what was used in IBM AS/400
|
|---|
| @marcus | k0ro: EROS itself also is multi-server based
|
|---|
| @marcus | xscript: wasn't it 360?
|
|---|
| @marcus | I don't know this area very well
| xscript | marcus: don't know, just read it, but not used it :)
marcus: Thanks, good to hear of
| xscript | in fact, capabilities is an idea from the '70s, if i remember well
|
|---|
| @marcus | k0ro: however, as I said, there are uncertainties.
|
|---|
| @marcus | in particular, the EROS design does not allow fine-grained self management of resources
|
|---|
| @marcus | this is _the_ major challenge
marcus: was capabilities the bigger problem in the Mach performance?
|
|---|
| @marcus | xscript: yes, the cap concept is very old
|
|---|
| @marcus | xscript: I wouldn't be surprised if you can trace it back to the 60s
marcus: or there was others problems too?
|
|---|
| @marcus | jlas9: Mach performance was analyzed very carefully. It turns out that one big issue is cache pollution, which leads to cache trashing
|
|---|
| @marcus | jlas9: ie, the kernel's working set was just too big
|
|---|
| @marcus | that's one problem
| xscript | that could be addressed with the L4/EROS small spaces "trick", and/or cache tagging
|
|---|
| @marcus | the other problem is that it has virtual memory management, but it doesn't have enough information to optimize page allocation
|
|---|
| @marcus | for example, it can't do read-ahead
| xscript | (not pollution, but flushing)
|
|---|
| @marcus | (on a file level)
|
|---|
| @marcus | xscript: the small spaces trick helps to avoid tlb flushes on context switch
|
|---|
| @marcus | xscript: but it does not help with the kernel's own working set
| xscript | marcus: that why i said that it helps preventing flushes :)
|
|---|
| @marcus | also, the Mach kernel just specifies too much policy
|
|---|
| @marcus | for example in the messaging system, message members are typed data structures (for network transparency)
|
|---|
| @marcus | the problem is that now you always pay for the type information, even if you don't need it
|
|---|
| @marcus | xscript: right. it's an important optimization, but usually the costs for client-server interaction are not considered when evaluating a microkernel IPC mechanism (because that's the "accepted" cost)
|
|---|
| @marcus | it's important that the microkernel doesn't impose additional cost
marcus: EROS not have a typed data structure for the messages?
|
|---|
| @marcus | well, there are two types
|
|---|
| @marcus | raw binary data and capabilities
|
|---|
| @marcus | the same is true for L4, if you look at it from the right angle
marcus: For the cache issue... can the working set of userland servers (for any microkernel) have the same problem?
|
|---|
| @marcus | k0ro: well, of course there is a cost at context switch
| xscript | marcus: talking about messages (and the net). I started thinking on a transparent distribution through what EROS present as the reference monitor (using distributed memory techniques), but this breaks all the properties of atomicity and upper time bounding that EROS has... but I think that's a problem inherent on a networked system :) Anyway, I think that EROS offers a good substrate for this kind of abstractions...
|
|---|
| @marcus | k0ro: but the client _wants_ to run the server code, right? so it's an accepted cost. at least that's one way to look at it.
|
|---|
| @marcus | k0ro: in a comparison of a monolithical kernel against a multi-server system, yes, this is an extra price you pay
|
|---|
| @marcus | xscript: that sounds good. however, it's way over my head :)
|
|---|
| @marcus | I prefer to side with Shapiro on this one.
|
|---|
| @marcus | "Let's first get a single-node system right."
| xscript | jeje, sure, it's just making "card castles on the air"
| zerog | uy que corteziano
| xscript | so, you think that Hurd should go towards eros? (I think this is a compromising question...)
|
|---|
| @marcus | xscript: reminds me of Shap's distributed persistent system
|
|---|
| @marcus | xscript: good for a lab, but if a crash in new york triggers a reboot in california...
|
|---|
| @marcus | xscript: mmh
| xscript | marcus: no idea of this shapiro's distributed sistem, EROS is relatively new to me :)
|
|---|
| @marcus | I think that the Hurd should not miss the opportunity to peek its nose into the EROS direction :)
|
|---|
| @marcus | the thing is that EROS shows us how to do secure systems right
| xscript | well, you don't have to convince me, is just that some people are more conservative....
|
|---|
| @marcus | there are political issues all over the place
| xscript | XD
|
|---|
| @marcus | but the truth is that I am not convinced in any direction yet
|
|---|
| @marcus | I thought I was going for L4, but I have doubts.
marcus: how much of the BSG's "Toward...." remains in a Hurd/Coyotos style system?
| xscript | I've read the story.... jejeje
|
|---|
| @marcus | since I started to have doubts, I have regained some confidence in some concepts, let go of some other concepts, and well, now I am going to evaluate this a bit more carefully :)
jlas9: depends on how you read it
|
|---|
| @marcus | jlas9: this is a good question. have you seen my email on that topic?
jlas9: the way marucs reads it, seems to be almost everything
jlas9: the way I read it, almost nothing
marcus: which mail, where can we read it?
| xscript | on hurd-l4, I think
ok, thanks
|
|---|
| @marcus | jlas9: http://lists.gnu.org/archive/html/l4-hurd/2005-10/msg00651.html
|
|---|
| @marcus | Subject: "Towards a New Strategy of OS Design" revisited
marcus: i go read it. Thanks!
|
|---|
| @marcus | bottom line is that the goals remain
|
|---|
| @marcus | and that we are more confident in fulfilling them
| xscript | away from distributing and any other funny things... is there a truly proposition for user-mode drivers over a capability-based system?
| xscript | i think this is a fairly important subject
|
|---|
| @marcus | user mode drivers are an essential part
|
|---|
| @marcus | they are a "must have" feature
|
|---|
| @marcus | there are several reasons
|
|---|
| @marcus | let me put an unconventional one up front
|
|---|
| @marcus | if we want to run unmodified linux drivers, we want to encapsulate them from the rest of the system
| xscript | i've been thinking about it, and the key is: a system on lower level enough to be expressive an with good performance, but high enough to give abstractions that don't let the user mess with the system
| xscript | the problem is the trust you have on them...
| xscript | (from linux or any other user...)
|
|---|
| @marcus | well, drivers must be trusted
|
|---|
| @marcus | because of the properties of the hardware (DMA
| xscript | right, but i should be able to use my home-made driver for my new USB/something dongle...
| xscript | or not?
|
|---|
| @marcus | As long as the something dongle is not a 1GBit ethernet link :)
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
