diff options
Diffstat (limited to 'microkernel')
| -rw-r--r-- | microkernel/mach/deficiencies.mdwn | 307 | ||||
| -rw-r--r-- | microkernel/mach/gnumach/boot_trace.mdwn | 22 |
2 files changed, 329 insertions, 0 deletions
diff --git a/microkernel/mach/deficiencies.mdwn b/microkernel/mach/deficiencies.mdwn index 8f47f61f..2e205a9a 100644 --- a/microkernel/mach/deficiencies.mdwn +++ b/microkernel/mach/deficiencies.mdwn @@ -2384,3 +2384,310 @@ In context of [[open_issues/multithreading]] and later [[open_issues/select]]. concurrently <braunr> (which is another contention issue when using mach-like ipc, which often do need to allocate/release virtual memory) + + +## IRC, freenode, #hurd, 2013-09-28 + + <rah> braunr: http://git.sceen.net/rbraun/x15.git/blob/HEAD:/README + <rah> "X15 is a free microkernel." + <rah> braunr: what distinguishes it from existing microkernels? + + +## IRC, freenode, #hurd, 2013-09-29 + + <braunr> rah: the next part maybe ? + <braunr> "Its purpose is to provide a foundation for a Hurd-like operating + system." + <rah> braunr: there are already microkernels that canbe used as the + foundatin for Hurd=like operating systems; why are you creating another + one? + <rah> braunr: what distinguishes your microkernel from existing + microkernels? + <tschwinge> rah: + http://www.gnu.org/software/hurd/microkernel/mach/deficiencies.html + <braunr> rah: it's better :) + <braunr> rah: and please, cite one suitable kernel for the hurd + <rah> tschwinge: those are deficiencies in Mach; I'm asking about x15 + <rah> braunr: in what way is it better exactly? + <braunr> rah: more performant, more scalable + <rah> braunr: how? + <braunr> better algorithms, better interfaces + <braunr> for example, it supports smp + <rah> ah + <rah> it supports SMP + <rah> ok + <rah> that's one thing + <braunr> it implements lockless synchronization à la rcu + <rah> are there any others? + <rah> ok + <rah> lockless sync + <rah> anything else? + <braunr> it can scale from 4MB of physical memory up to several hundreds + GiB + <braunr> ipc is completely different, leading to simpler code, less data + involved, faster context switches + <braunr> (although there is no code for that yet) + <rah> how can it support larger memory while other microkernels can't? + <rah> how is the ipc "different"? + <braunr> others can + <braunr> gnumach doesn't + <rah> how can it support larger memory while gnumach can't? + <azeem_> because it's not the same code base? + <braunr> gnumach doesn't support temporary kernel mapping + <rah> ok, so x15 supports temporary kernel mapping + <braunr> not exactly + <braunr> virtual memory is completely different + <rah> how so? + <braunr> gnumach does the same as linux, physical memory is mapped in + kernel space + <braunr> so you can't have more physical memory than you have kernel space + <braunr> which is why gnumach can't handle more than 1.8G right now + <braunr> it's a 2/2 split + <braunr> in x15, the kernel maps what it needs + <braunr> and can map it from anywhere in physical memory + <tschwinge> rah: I think basically all this has already been discussed + before and captured on that page? + <braunr> it already supports i386/pae/amd64 + <rah> I see + <braunr> the drawback is that it needs to update kernel page tables more + often + <braunr> on linux, a small part of the kernel space is reserved for + temporary mappings, which need page table updates too + <braunr> but most allocations don't use that + <braunr> it's complicated + <braunr> also, i plan to make virtual memory operations completely + concurrent on x15, similar to what is described in radixvm + <rah> ok + <braunr> which means mapping operations on non overlapping regions won't be + serialized + <braunr> a big advantage for microkernels which base their messaging + optimizations on mapping + <braunr> so simply put, better performance because of simpler ipc and data + structures, and better scalability because of improved data structure + algorithms and concurrency + <rah> tschwinge: yes but that page is no use to someone who wants a summary + of what distinguishes x15 + <braunr> x15 is still far from complete, which is why i don't advertise it + other than here + <rah> "release early, release often"? + <braunr> give it a few more years :p + <braunr> release what ? + <braunr> something that doesn't work ? + <rah> software + <rah> yes + <braunr> this release early practice applies to maintenance + <rah> release something that doesn't work so that others can help make it + work + <braunr> not big developments + <braunr> i don't want that for now + <braunr> i have a specific idea of what i want, and both explaining and + defending it would take time, better spent in development itself + <braunr> just wait for a first prototype + <braunr> and then you'll see if you want to help or not + * rah does not count himself as one of the "others" who might help make it + work + <braunr> one big difference with other microkernels is that x15 is + specifically intended to run a unix like system + <braunr> a hurd like system providing a psoix interface more accurately + <braunr> and efficiently + <braunr> so for example, while many microkernels provide only sync ipc, x15 + provides both sync ipc and signals + <braunr> and then, there are a lot of small optimizations, like port names + which will transparently identify as file descriptors + <braunr> light reference counting + <braunr> a restriction on ipc that only allows reliable transfers across + network to machines with same arch and endianness + <braunr> etc.. + <rah> http://darnassus.sceen.net/~hurd-web/microkernel/x15/ + <rah> please take note of the fact that this newly created page is not just + a dump of IRC logs + + +## IRC, freenode, #hurd, 2013-09-30 + + <braunr> rah: i'm uncomfortable with a page about x15 on the wiki ... + <braunr> there is a reason i don't want to advertise it for now + <braunr> and you're just completely ignoring it + <rah> braunr: detailed information about x15 is already included elsewhere + in the wiki + <braunr> rah: really ? + <rah> braunr: there is a section named "X15" on this page: + http://www.gnu.org/software/hurd/microkernel/mach/deficiencies.html + <braunr> rah: oh ok, but it's still small and hard to find ;p + <rah> braunr: "small"?! + <rah> braunr: the X15 section starts at about 10% down the page and + finishes at the bottom of the page + <rah> braunr: and the page is huge + <braunr> rah: hm ok, but that's still listed as mach deficiencies, not as + x15 itself + <rah> braunr: I heard about x15 + <rah> braunr: I wanted to learn about it + <rah> braunr: there was no easily accessible information for doing so + <rah> braunr: it's not unreasonable to want to learn about it, having heard + about it + <rah> braunr: others will want to learn about it + <azeem_> rah: please respect the developer's policy of how to advertise + their project + <rah> braunr: having learned about it myself, I've helped those who will + follow me by giving them the summary that I wanted + <rah> azeem_: I'm not disrespecting the developer's policy of how to + advertise their project; I'm not advertising their project + <azeem_> rah: maybe replace the wiki page by "If you would like to know + about X15, please contact <your email>" + <rah> azeem_: that's ridiculous + <braunr> rah: then ask me directly + <braunr> rah: don't make wiki pages + <rah> braunr: I don't understand what you mean + <rah> braunr: I have already asked you directly + <rah> braunr: I needed to ask you directly in order to make the wiki page + <azeem> rah: braunr does not like your wiki page, how hard is it to + understand? + <rah> azeem: my discussion is with braunr, not you + <braunr> rah: if someone wants to know more about x15, he can me directly, + no need for a wiki page + + +## IRC, freenode, #hurd, 2013-10-01 + + <rah> braunr: that's hyperbole; there's no "need" for a wiki, or for x15 or + even for the Hurd + <rah> braunr: a wiki page is helpful + <rah> useful, even + <braunr> rah: as azeem said, i'm just not willing to advertise outside this + channel for now + <braunr> it makes sense to mention it in the defficiencies page, since this + page talks about what's lacking in gnumach + <braunr> and the wiki is about the hurd, including gnumach + <rah> braunr: why does it make sense to mention it in the deficiencies page + but not in a dedicated page? + <braunr> rah: because gnumach is a hurd project, x15 isn't + <rah> braunr: what do you mean by "a hurd project"? + <rah> braunr: you're saying that x15 differs from gnumach in some way, and + that this difference is the reason it doesn't make sense to have a wiki + page devoted to x15; the phrase you've used to descibe that difference is + "a hurd project" but it's not clear what, exactly, you mean by that + <rah> braunr: could you explain what you mean by that? + <azeem> rah: this is getting off-topic, please take this conversation + elsewhere + <rah> azeem: that's a very tenuous statement + <rah> azeem: I think this is the appropriate place to discuss the matter + <azeem> I leave that to braunr to decide + <rah> azeem: I think *you* don't want the conversation to be had at all and + are attempting to censor it using a tenuous excuse + <azeem> no no, I'm not censoring it - I am just saying you should take it + elsewhere + <braunr> let's take it elsewhere + + +## IRC, freenode, #hurd, 2013-10-12 + + <zacts> braunr: are you still working on x15/propel? + * zacts checks the git logs + <braunr> zacts: taking a break for now, will be back on it when i have a + clearer view of the new vm system + + +## IRC, freenode, #hurd, 2013-10-15 + + <gnufreex> braunr, few questions about x15. I was reading IRC logs on hurd + site, and in the latest part, you say (or I misunderstood) that x15 is + now hybrid kernel. So what made you change design... or did you? + <braunr> gnufreex: i always intended to go for a hybrid + + +## IRC, freenode, #hurd, 2013-10-19 + + <zacts> braunr: when do you plan to start on x15/propel again? + <braunr> zacts: after i'm done with thread destruction on the hurd + +[[open_issues/libpthread/t/fix_have_kernel_resources]]. + + <zacts> and do you plan to actually run hurd on top of x15, or are you + still going to reimplement hurd as propel? + <braunr> and no, i don't intend to run the hurd on top of x15 + + +## IRC, freenode, #hurd, 2013-10-24 + + <neal> braunr: What is your Mach replacement doing? + <braunr> "what" ? :) + <braunr> you mean how i guess + <neal> Sure. + <braunr> well it's not a mach replacement any more + <braunr> and for now it's stalled while i'm working on the hurd + <neal> that could be positive :) + <braunr> it's in good shape + <neal> how did it diverge? + <braunr> sync ipc, with unix-like signals + <braunr> and qnx-like bare data messages + <neal> hmm, like okl5? + <braunr> (with scatter gather) + <neal> okl4 + <braunr> yes + <braunr> btw, if you can find a document that explains this property of + okl4, i'm interested, since i can't find it again on my own :/ + <braunr> basically, x15 has a much lighter ipc interface + <neal> capabilities? + <braunr> mach ports are mostly retained + <braunr> but reference counting will be simplified + <neal> hmm + <neal> I don't like the reference counting part + <braunr> port names will be plain integers, to directly be usable as file + descriptors and avoid a useless translation layer + <braunr> (same as in qnx) + <neal> this sounds like future tense + <braunr> there is no ipc code yet + <neal> so I guess this stuff is not implemented + <neal> ok. + <braunr> next step is virtual memory + <braunr> and i'm taking my time because i want it to be a killer feature + <neal> so if you don't IPC and you don't have VM, what do you have? :) + <braunr> i have multiprocessor multithreading + <neal> I see. + <braunr> mutexes, condition variables, rcu-like lockless synchronization, + work queues + <braunr> basic bsd-like virtual memory + <braunr> which i want to rework + <neal> I ignored all of that in Viengoos :) + <braunr> and since ipc will still depend on virtual memory for zero-copy, i + want the vm system to be right + <braunr> well, i'm more interested in the implementation than the + architecture + <braunr> for example, i have unpublished code that features a lockless + radix tree for vm_object lookups + <braunr> that's quite new for a microkernel based system, but the ipc + interface itself is very similar to what already exists + <braunr> your half-sync ipc are original :) + <neal> I'm considering getting back in the OS game. + <braunr> oh + <neal> But, I'm not going to write a kernel this time. + <braunr> did anyone here consider starting a company for such things, like + genode did ? + <neal> I was considering using genode as a base. + <braunr> neal: why genode ? + <neal> I want to build a secure system. + <neal> I think the best way to do that is using capabilities. + <neal> Genode runs on Fiasco.OC, for instance + <neal> and it provides a lot of infrastructure + <braunr> neal: why not l4re for example ? + <braunr> neal: how important is the ability to revoke capabilities ? + +In the discussion on [[community/gsoc/project_ideas/object_lookups]], *IRC, +freenode, #hurd, 2013-10-24*: + + <teythoon> and, with some effort, getting rid of the hash table lookup by + letting the kernel provide the address of the object (iirc neil knew the + proper term for that) + <braunr> teythoon: that is a big interface change + <teythoon> how so + <braunr> optimizing libihash and libpthread should already be a good start + <braunr> well how do you intend to add this information ? + <braunr> ok, "big" is overstatement, but still, it's a low level interface + change that would probably break a lot of things + <teythoon> store a pointer in the port structure in gnumach, make that + accessible somehow + <braunr> yes but how ? + <teythoon> interesting question indeed + <braunr> my plan for x15 is to make this "label" part of received messages + <braunr> which means you need to change the format of messages + <braunr> that is what i call a big change diff --git a/microkernel/mach/gnumach/boot_trace.mdwn b/microkernel/mach/gnumach/boot_trace.mdwn index 7b729c23..ea999a9b 100644 --- a/microkernel/mach/gnumach/boot_trace.mdwn +++ b/microkernel/mach/gnumach/boot_trace.mdwn @@ -227,3 +227,25 @@ License|/fdl]]."]]"""]] >> vm\_pageout >> Does not return. + + +# IRC, freenode, #hurd, 2013-10-07 + + <cureOS> look, where should i dig or where from should i start from, if i + have desire to know how the kernel was written from baremetal? Can it be + ever done nowadays? + <youpi> cureOS: the boot entry of the kernel is i386/i386at/boothdr.S , + boot_entry + <youpi> that's what grub jumps to + <youpi> then that jumps to c_boot_entry + <youpi> and everything else is C + <cureOS> grub loads it somehow. how does it prepare cpu and memoty, cpu + cache control if any... segments for stack.. + <youpi> see the grub documentation + <youpi> basically it's all flat linear space + <cureOS> does kernel transform it after that? + <youpi> see the ldt/gdt initialization + <youpi> from i386at_init and children + <youpi> nothing much fancy, a kernel cs/ds, and user cs/ds + <braunr> and paging, naturally + <youpi> sure |