VI International Conference of Unix at Uninet
  • Presentation
  • Register
  • Program
  • Organizing Comittee
  • Listing of registered people
  • Translators team
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 :)
xscript something like what happens with file systems... i can use my own... marcus: ok, i see you and Jonathan Shapiro too, are agree basically with the Thomas objetives...
@marcus jlas9: yes. don't forget that this was always, and still is, my starting point
xscript but the trust line is not much clear... marcus: ok
@marcus I have ended up in the situation I am (making the design decisions I do) based on these principles and goals
@marcus in pursueing to fulfill them technically [2005-12-19 15:05:46]
@marcus xscript: unfortunately I don't know too much about hardware issues, but my understanding is that some high level protocol you can probably run in untrusted user space
@marcus xscript: but the low level drivers must be trusted xscript: there are different opinions on how drivers should be handled. mine is that they shold be handled *exactly* like filesystems
xscript ok, so it's more or less as what I though (in my lack of hw knowledge) of a two-level driver scheme
xscript antrik: like filesystems? so something like linux's... sys? isn't it?
xscript this way, the sys-like part (bus controlling and resource (de)multiplexation) could be run by trusted code, and have some user-code attached to it... but that's still unsecure...
@marcus ok. I will leave these windows open for a while, and have some dinner. thanks to everybody for the interesting questions. stay tuned and check out what we are up to on the l4-hurd mailing list, in addition to the hurd mailing lists, documented on hurd.gnu.org. See you later!

© 2005 - www.uninet.edu - Contact Organizing Comittee - Valid XHTML - Valid CSS - Based on a design by Raul Pérez Justicia