From 47e4d194dc36adfcfd2577fa4630c9fcded005d3 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 27 Oct 2013 19:15:06 +0100 Subject: IRC. --- microkernel/mach/deficiencies.mdwn | 307 +++++++++++++++++++++++++++++++ microkernel/mach/gnumach/boot_trace.mdwn | 22 +++ 2 files changed, 329 insertions(+) (limited to 'microkernel') 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 (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 + + braunr: http://git.sceen.net/rbraun/x15.git/blob/HEAD:/README + "X15 is a free microkernel." + braunr: what distinguishes it from existing microkernels? + + +## IRC, freenode, #hurd, 2013-09-29 + + rah: the next part maybe ? + "Its purpose is to provide a foundation for a Hurd-like operating + system." + braunr: there are already microkernels that canbe used as the + foundatin for Hurd=like operating systems; why are you creating another + one? + braunr: what distinguishes your microkernel from existing + microkernels? + rah: + http://www.gnu.org/software/hurd/microkernel/mach/deficiencies.html + rah: it's better :) + rah: and please, cite one suitable kernel for the hurd + tschwinge: those are deficiencies in Mach; I'm asking about x15 + braunr: in what way is it better exactly? + rah: more performant, more scalable + braunr: how? + better algorithms, better interfaces + for example, it supports smp + ah + it supports SMP + ok + that's one thing + it implements lockless synchronization à la rcu + are there any others? + ok + lockless sync + anything else? + it can scale from 4MB of physical memory up to several hundreds + GiB + ipc is completely different, leading to simpler code, less data + involved, faster context switches + (although there is no code for that yet) + how can it support larger memory while other microkernels can't? + how is the ipc "different"? + others can + gnumach doesn't + how can it support larger memory while gnumach can't? + because it's not the same code base? + gnumach doesn't support temporary kernel mapping + ok, so x15 supports temporary kernel mapping + not exactly + virtual memory is completely different + how so? + gnumach does the same as linux, physical memory is mapped in + kernel space + so you can't have more physical memory than you have kernel space + which is why gnumach can't handle more than 1.8G right now + it's a 2/2 split + in x15, the kernel maps what it needs + and can map it from anywhere in physical memory + rah: I think basically all this has already been discussed + before and captured on that page? + it already supports i386/pae/amd64 + I see + the drawback is that it needs to update kernel page tables more + often + on linux, a small part of the kernel space is reserved for + temporary mappings, which need page table updates too + but most allocations don't use that + it's complicated + also, i plan to make virtual memory operations completely + concurrent on x15, similar to what is described in radixvm + ok + which means mapping operations on non overlapping regions won't be + serialized + a big advantage for microkernels which base their messaging + optimizations on mapping + so simply put, better performance because of simpler ipc and data + structures, and better scalability because of improved data structure + algorithms and concurrency + tschwinge: yes but that page is no use to someone who wants a summary + of what distinguishes x15 + x15 is still far from complete, which is why i don't advertise it + other than here + "release early, release often"? + give it a few more years :p + release what ? + something that doesn't work ? + software + yes + this release early practice applies to maintenance + release something that doesn't work so that others can help make it + work + not big developments + i don't want that for now + i have a specific idea of what i want, and both explaining and + defending it would take time, better spent in development itself + just wait for a first prototype + 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 + one big difference with other microkernels is that x15 is + specifically intended to run a unix like system + a hurd like system providing a psoix interface more accurately + and efficiently + so for example, while many microkernels provide only sync ipc, x15 + provides both sync ipc and signals + and then, there are a lot of small optimizations, like port names + which will transparently identify as file descriptors + light reference counting + a restriction on ipc that only allows reliable transfers across + network to machines with same arch and endianness + etc.. + http://darnassus.sceen.net/~hurd-web/microkernel/x15/ + 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 + + rah: i'm uncomfortable with a page about x15 on the wiki ... + there is a reason i don't want to advertise it for now + and you're just completely ignoring it + braunr: detailed information about x15 is already included elsewhere + in the wiki + rah: really ? + braunr: there is a section named "X15" on this page: + http://www.gnu.org/software/hurd/microkernel/mach/deficiencies.html + rah: oh ok, but it's still small and hard to find ;p + braunr: "small"?! + braunr: the X15 section starts at about 10% down the page and + finishes at the bottom of the page + braunr: and the page is huge + rah: hm ok, but that's still listed as mach deficiencies, not as + x15 itself + braunr: I heard about x15 + braunr: I wanted to learn about it + braunr: there was no easily accessible information for doing so + braunr: it's not unreasonable to want to learn about it, having heard + about it + braunr: others will want to learn about it + rah: please respect the developer's policy of how to advertise + their project + braunr: having learned about it myself, I've helped those who will + follow me by giving them the summary that I wanted + azeem_: I'm not disrespecting the developer's policy of how to + advertise their project; I'm not advertising their project + rah: maybe replace the wiki page by "If you would like to know + about X15, please contact " + azeem_: that's ridiculous + rah: then ask me directly + rah: don't make wiki pages + braunr: I don't understand what you mean + braunr: I have already asked you directly + braunr: I needed to ask you directly in order to make the wiki page + rah: braunr does not like your wiki page, how hard is it to + understand? + azeem: my discussion is with braunr, not you + 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 + + braunr: that's hyperbole; there's no "need" for a wiki, or for x15 or + even for the Hurd + braunr: a wiki page is helpful + useful, even + rah: as azeem said, i'm just not willing to advertise outside this + channel for now + it makes sense to mention it in the defficiencies page, since this + page talks about what's lacking in gnumach + and the wiki is about the hurd, including gnumach + braunr: why does it make sense to mention it in the deficiencies page + but not in a dedicated page? + rah: because gnumach is a hurd project, x15 isn't + braunr: what do you mean by "a hurd project"? + 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 + braunr: could you explain what you mean by that? + rah: this is getting off-topic, please take this conversation + elsewhere + azeem: that's a very tenuous statement + azeem: I think this is the appropriate place to discuss the matter + I leave that to braunr to decide + azeem: I think *you* don't want the conversation to be had at all and + are attempting to censor it using a tenuous excuse + no no, I'm not censoring it - I am just saying you should take it + elsewhere + let's take it elsewhere + + +## IRC, freenode, #hurd, 2013-10-12 + + braunr: are you still working on x15/propel? + * zacts checks the git logs + 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 + + 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? + gnufreex: i always intended to go for a hybrid + + +## IRC, freenode, #hurd, 2013-10-19 + + braunr: when do you plan to start on x15/propel again? + zacts: after i'm done with thread destruction on the hurd + +[[open_issues/libpthread/t/fix_have_kernel_resources]]. + + and do you plan to actually run hurd on top of x15, or are you + still going to reimplement hurd as propel? + and no, i don't intend to run the hurd on top of x15 + + +## IRC, freenode, #hurd, 2013-10-24 + + braunr: What is your Mach replacement doing? + "what" ? :) + you mean how i guess + Sure. + well it's not a mach replacement any more + and for now it's stalled while i'm working on the hurd + that could be positive :) + it's in good shape + how did it diverge? + sync ipc, with unix-like signals + and qnx-like bare data messages + hmm, like okl5? + (with scatter gather) + okl4 + yes + 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 :/ + basically, x15 has a much lighter ipc interface + capabilities? + mach ports are mostly retained + but reference counting will be simplified + hmm + I don't like the reference counting part + port names will be plain integers, to directly be usable as file + descriptors and avoid a useless translation layer + (same as in qnx) + this sounds like future tense + there is no ipc code yet + so I guess this stuff is not implemented + ok. + next step is virtual memory + and i'm taking my time because i want it to be a killer feature + so if you don't IPC and you don't have VM, what do you have? :) + i have multiprocessor multithreading + I see. + mutexes, condition variables, rcu-like lockless synchronization, + work queues + basic bsd-like virtual memory + which i want to rework + I ignored all of that in Viengoos :) + and since ipc will still depend on virtual memory for zero-copy, i + want the vm system to be right + well, i'm more interested in the implementation than the + architecture + for example, i have unpublished code that features a lockless + radix tree for vm_object lookups + that's quite new for a microkernel based system, but the ipc + interface itself is very similar to what already exists + your half-sync ipc are original :) + I'm considering getting back in the OS game. + oh + But, I'm not going to write a kernel this time. + did anyone here consider starting a company for such things, like + genode did ? + I was considering using genode as a base. + neal: why genode ? + I want to build a secure system. + I think the best way to do that is using capabilities. + Genode runs on Fiasco.OC, for instance + and it provides a lot of infrastructure + neal: why not l4re for example ? + 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*: + + 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) + teythoon: that is a big interface change + how so + optimizing libihash and libpthread should already be a good start + well how do you intend to add this information ? + ok, "big" is overstatement, but still, it's a low level interface + change that would probably break a lot of things + store a pointer in the port structure in gnumach, make that + accessible somehow + yes but how ? + interesting question indeed + my plan for x15 is to make this "label" part of received messages + which means you need to change the format of messages + 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 + + 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? + cureOS: the boot entry of the kernel is i386/i386at/boothdr.S , + boot_entry + that's what grub jumps to + then that jumps to c_boot_entry + and everything else is C + grub loads it somehow. how does it prepare cpu and memoty, cpu + cache control if any... segments for stack.. + see the grub documentation + basically it's all flat linear space + does kernel transform it after that? + see the ldt/gdt initialization + from i386at_init and children + nothing much fancy, a kernel cs/ds, and user cs/ds + and paging, naturally + sure -- cgit v1.2.3 From 99b0cf260e603de1b3b6b99a98f6b136ee09098e Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 27 Oct 2013 23:19:17 +0100 Subject: open_issues/versioning: New. --- microkernel/mach/message/msgh_id.mdwn | 2 ++ open_issues/glibc.mdwn | 2 ++ open_issues/glibc/0.4.mdwn | 32 ----------------- open_issues/versioning.mdwn | 67 +++++++++++++++++++++++++++++++++++ 4 files changed, 71 insertions(+), 32 deletions(-) delete mode 100644 open_issues/glibc/0.4.mdwn create mode 100644 open_issues/versioning.mdwn (limited to 'microkernel') diff --git a/microkernel/mach/message/msgh_id.mdwn b/microkernel/mach/message/msgh_id.mdwn index 799ed5cc..b20f1fe0 100644 --- a/microkernel/mach/message/msgh_id.mdwn +++ b/microkernel/mach/message/msgh_id.mdwn @@ -15,6 +15,8 @@ files. [[!toc]] +See also [[open_issues/versioning]]. + # IRC, freenode, #hurd, 2012-07-12 diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn index 292c6256..23339bac 100644 --- a/open_issues/glibc.mdwn +++ b/open_issues/glibc.mdwn @@ -18,6 +18,8 @@ Here's what's to be done for maintaining glibc. # [[General information|/glibc]] +## [[Versioning]] + # [[Sources|source_repositories/glibc]] diff --git a/open_issues/glibc/0.4.mdwn b/open_issues/glibc/0.4.mdwn deleted file mode 100644 index f864469d..00000000 --- a/open_issues/glibc/0.4.mdwn +++ /dev/null @@ -1,32 +0,0 @@ -[[!meta copyright="Copyright © 2012, 2013 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled [[GNU Free Documentation -License|/fdl]]."]]"""]] - -[[!tag open_issue_glibc open_issue_libpthread]] - -Things to consider doing when bumping the glibc SONAME. - - -# IRC, freenode, #hurd, 2012-12-14 - -In context of [[packaging_libpthread]]/[[libpthread]]. - - once libc is switched internally from cthreads to pthreads (thus - breaking its BC), may be worth cleanup the hurd-specific exported symbols - pinotree: Yes. If you already have ideas about what to clean - up, feel free to add a new page or a section on open_issues/glibc. - we're gonna break backwards compatibility in glibc on hurd? that - could be the perfect moment to fix the /dev/fd/N problem without adding - new RPCs, though we'd probably have to break backwards-compatibility in - the exec server IIRC... - pochu: Oh, I have to re-read that discussion, but thanks for - reminding! - -[[!GNU_Savannah_bug 28934]], [[user/pochu]], [[!message-id -"4BFA500A.7030502@gmail.com"]]. diff --git a/open_issues/versioning.mdwn b/open_issues/versioning.mdwn new file mode 100644 index 00000000..69a6cb20 --- /dev/null +++ b/open_issues/versioning.mdwn @@ -0,0 +1,67 @@ +[[!meta copyright="Copyright © 2012, 2013 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +Things to consider regarding *versioning*. + +The provider and user of any interface need to agree about how to interpret the +data being exchanged. Internal-only interfaces can be changed easily, because +you can change the provider and user at the same time. Interfaces that are +exposed externally require more attention, for obvious reasons. To *change* +interfaces means to either remove, or add, or modify an existing interface. +Modify basically means to remove and then re-add a variant, re-using the former +name/identifier. + + +# [[RPC]]s + +## [[microkernel/mach/message/msgh_id]] + + +# Shared Libraries + + * [[!wikipedia soname]] + * ELF symbol versioning + * [[!wikipedia "GNU Libtool"]] + + +## Hurd + +Transition to "normal" ELF symbol versioning/libtool? + +For all libraries, the SONAME is currently set to *0.3*. [[!message-id +desc="Not changed" "87ob7cxbu6.fsf@kepler.schwinge.homeip.net"]] when doing the +[[Hurd 0.5 release|news/2013-09-27]]. + + +## glibc + +Bump the glibc SONAME to some point, or can do everything with symbol +versioning? + + +### IRC, freenode, #hurd, 2012-12-14 + +[[!tag open_issue_glibc open_issue_libpthread]] + +In context of [[packaging_libpthread]]/[[libpthread]]. + + once libc is switched internally from cthreads to pthreads (thus + breaking its BC), may be worth cleanup the hurd-specific exported symbols + pinotree: Yes. If you already have ideas about what to clean + up, feel free to add a new page or a section on open_issues/glibc. + we're gonna break backwards compatibility in glibc on hurd? that + could be the perfect moment to fix the /dev/fd/N problem without adding + new RPCs, though we'd probably have to break backwards-compatibility in + the exec server IIRC... + pochu: Oh, I have to re-read that discussion, but thanks for + reminding! + +[[!GNU_Savannah_bug 28934]], [[user/pochu]], [[!message-id +"4BFA500A.7030502@gmail.com"]]. -- cgit v1.2.3