From 12c341b917921eb631026ec44a284c4d884e5de6 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 6 Mar 2013 21:52:20 +0100 Subject: IRC. --- microkernel/mach/deficiencies.mdwn | 87 ++++++++++++++++++++++ microkernel/mach/gnumach/interface.mdwn | 16 ++++ microkernel/mach/gnumach/interface/syscall.mdwn | 16 ++++ .../mach/gnumach/interface/syscall/mach_print.mdwn | 53 +++++++++++++ microkernel/mach/gnumach/memory_management.mdwn | 13 +++- microkernel/mach/message/msgh_id.mdwn | 26 ++++++- 6 files changed, 209 insertions(+), 2 deletions(-) create mode 100644 microkernel/mach/gnumach/interface.mdwn create mode 100644 microkernel/mach/gnumach/interface/syscall.mdwn create mode 100644 microkernel/mach/gnumach/interface/syscall/mach_print.mdwn (limited to 'microkernel') diff --git a/microkernel/mach/deficiencies.mdwn b/microkernel/mach/deficiencies.mdwn index 9ba67219..b3e1758c 100644 --- a/microkernel/mach/deficiencies.mdwn +++ b/microkernel/mach/deficiencies.mdwn @@ -528,3 +528,90 @@ In context of [[open_issues/multithreading]] and later [[open_issues/select]]. physical maps (cpu-specific page tables) for user tasks, and stack tracing (in addition to symbol resolution when symbols are available) were recently added + + +### IRC, freenode, #hurd, 2013-01-15 + + Anarchos: as a side note, i'm currently working on a hurd clone + with a microkernel that takes a lot from mach but also completely changes + the ipc interface (making it not mach at all in the end) + it's something between mach and qnx neutrino + braunr: do you have a git repo of your new clone? + http://git.sceen.net/rbraun/x15.git/ + neat + it's far from complete + and hasn't reached a status where it can be publically announced + ok + but progress has been constant so far, the ideas i'm using have + proven applicable on other systems, i don't expect the kind of design + issues that blocked HurdNG + (also, my attempt doesn't aim at the same goals as hurdng did) + (e.g. denial of service remains completely possible) + so x15 will use the current hurd translators? you are only + replacing gnumach? + that was the plan some years ago, but now that i know the hurd + better, i think the main issues are in the hurd, so there isn't much + point rewriting mach + so, if the hurd needs a revamp, it's better to also make the + underlying interface better if possible + zacts: in other words: it's a completely different beast + ok + the main goal is to create a hurd-like system that overcomes the + current major defficiencies, most of them being caused by old design + decisions + like async ipc? + yes + time for a persistent hurd ? :) + no way + i don't see a point to persistence for a general purpose system + and it easily kills performance + on the other hand, it would be nice to have a truely scalable, + performant, and free microkernel based system + (and posix compatible) + there is currently none + zacts: the projects focuses mostly on performance and scalability, + while also being very easy to understand and maintain (something i think + the current hurd has failed at :/) + project* + very cool + i think so, but we'll have to wait for an end result :) + what's currently blocking me is the IDL + earlier research has shown that an idl must be optmized the same + way compilers are for the best performances + i'm not sure i can write something good enough :/ + the first version will probably be very similar to mig, small and + unoptimized + + +### IRC, freenode, #hurd, 2013-01-18 + + braunr: so how exactly do the goals of x15 differ from viengoos? + zacts: viengoos is much more ambitious about the design + tbh, i still don't clearly see how its half-sync ipc work + x15 is much more mach-like, e.g. a hybrid microkernel with + scheduling and virtual memory in the kernel + its goals are close to those of mach, adding increased scalability + and performance to the list + that's neat + that's different + in a way, you could consider x15 is to mach what linux is to unix, + a clone with a "slightly" different interface + ah, ok. cool! + viengoos is rather a research project, with very interesting + goals, i think they're both neat :p + + +### IRC, freenode, #hurd, 2013-01-19 + + for now, it provides kernel memory allocation and basic threading + it already supports both i386 and amd64 processors (from i586 + onwards), and basic smp + oh wow + how easily can it be ported to other archs? + the current focus is smp load balancing, so that thread migration + is enabled during development + hard to say + everything that is arch-specific is cleanly separated, the same + way it is in mach and netbsd + but the arch-specific interfaces aren't well defined yet because + there is only one (and incomplete) arch diff --git a/microkernel/mach/gnumach/interface.mdwn b/microkernel/mach/gnumach/interface.mdwn new file mode 100644 index 00000000..b2451887 --- /dev/null +++ b/microkernel/mach/gnumach/interface.mdwn @@ -0,0 +1,16 @@ +[[!meta copyright="Copyright © 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]]."]]"""]] + +[[!meta title="Interfaces"]] + +/!\ Incomplete. + +[[!map pages="microkernel/mach/gnumach/interface/*" +show=title]] diff --git a/microkernel/mach/gnumach/interface/syscall.mdwn b/microkernel/mach/gnumach/interface/syscall.mdwn new file mode 100644 index 00000000..d5fc542b --- /dev/null +++ b/microkernel/mach/gnumach/interface/syscall.mdwn @@ -0,0 +1,16 @@ +[[!meta copyright="Copyright © 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]]."]]"""]] + +[[!meta title="System Calls"]] + +/!\ Incomplete. + +[[!map pages="microkernel/mach/gnumach/interface/syscall/* and !microkernel/mach/gnumach/interface/syscall/*/*" +show=title]] diff --git a/microkernel/mach/gnumach/interface/syscall/mach_print.mdwn b/microkernel/mach/gnumach/interface/syscall/mach_print.mdwn new file mode 100644 index 00000000..c0b0d0b3 --- /dev/null +++ b/microkernel/mach/gnumach/interface/syscall/mach_print.mdwn @@ -0,0 +1,53 @@ +[[!meta copyright="Copyright © 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]]."]]"""]] + + +# IRC, freenode, #hurd, 2013-01-18 + + youpi: what would you think of adding a debug-related syscall to + gnumach so that we have a printf-like tool even in situations where the + code can't perform an rpc (i.e. glibc) + could be useful indeed + I've found myself having a hard time making some printfs from odd + places of glibc :) + i also suggest we make it unprivileged + not enabled by default then + otherwise it's an easy DoS + well, for now, we don't care much about DoS, but we do care about + debugging + at least until the very core issues we have are understood and + resolved + I usually frown on debugging feature being too open + me too + you would always forget dropping one + that's why i didn't suggest it earlier + but i'm wasting too much time finding other decently effective + ways + + +## IRC, freenode, #hurd, 2013-01-19 + + youpi: how about we build this debugging system call in debugging + versions only ? + i suppose you already use such versions for buildds anyway + MACH_DEBUG is always enabled + the debugging version only adds --enable-kdb if i'm right + check debian/rules + that, and -fno-omit-frame-pointer + + +## IRC, freenode, #hurd, 2013-01-21 + + youpi: concerning gnumach, i've added a mach_print system call, + with one argument (a null terminated string) to -dbg kernels + (--enable-kbd) + k + if it's fine with you, i'll commit it too + I'm fine diff --git a/microkernel/mach/gnumach/memory_management.mdwn b/microkernel/mach/gnumach/memory_management.mdwn index a1d9a99d..4e237269 100644 --- a/microkernel/mach/gnumach/memory_management.mdwn +++ b/microkernel/mach/gnumach/memory_management.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 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 @@ -177,3 +178,13 @@ License|/fdl]]."]]"""]] again, i was just wondering out loud braunr: well, bach & mozart don't have > 1.2GiB mem anyway so it doesn't pose problem + + +# IRC, freenode, #hurd, 2013-01-12 + + can hurd have more than 1GB of ram ? + sobhan: not with the stock kernel, but yes with a simple patch + sobhan: although you should be aware of the implications of this + patch + (more kernel memory, thus more physical memory - up to 1.8 GiB - + but then, less user memory) diff --git a/microkernel/mach/message/msgh_id.mdwn b/microkernel/mach/message/msgh_id.mdwn index a7157a37..ea52904a 100644 --- a/microkernel/mach/message/msgh_id.mdwn +++ b/microkernel/mach/message/msgh_id.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] +[[!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 @@ -257,3 +257,27 @@ files. ## IRC, freenode, #hurd, 2012-09-30 youpi: hey, didn't see you merged the page cache stats branch :) + + +## IRC, freenode, #hurd, 2013-01-12 + + youpi: the hurd master-vm_cache_stats branch (which makes vmstat + displays some vm cache properties) is ready to be pulled + +[[open_issues/mach_tasks_memory_usage]]. + + tschwinge: i've updated the procfs server on darnassus, you can + now see the amount of physical memory used by the vm cache with top/htop + (not vmstat yet) + + +### IRC, freenode, #hurd, 2013-01-13 + + braunr: I'm not sure to understand what I'm supposed to do with the + page cache statistics branch + youpi: apply it ? + can't you already do that? + well, i don't consider myself a maintainer + then submit to the list for review + hm ok + youpi: ok, next time, i'll commit such changes directly -- cgit v1.2.3