summaryrefslogtreecommitdiff
path: root/microkernel/mach
diff options
context:
space:
mode:
Diffstat (limited to 'microkernel/mach')
-rw-r--r--microkernel/mach/deficiencies.mdwn307
-rw-r--r--microkernel/mach/gnumach/boot_trace.mdwn22
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