From be4193108513f02439a211a92fd80e0651f6721b Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 30 Nov 2011 21:21:45 +0100 Subject: IRC. --- hurd/debugging/rpctrace.mdwn | 37 ++++++++++++++++++++++++++ hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn | 37 ++++++++++++++++++++++++++ hurd/virtual_file_system/discussion.mdwn | 39 ++++++++++++++++++++++++++++ 3 files changed, 113 insertions(+) create mode 100644 hurd/virtual_file_system/discussion.mdwn (limited to 'hurd') diff --git a/hurd/debugging/rpctrace.mdwn b/hurd/debugging/rpctrace.mdwn index f7136056..fd24f081 100644 --- a/hurd/debugging/rpctrace.mdwn +++ b/hurd/debugging/rpctrace.mdwn @@ -52,6 +52,43 @@ See `rpctrace --help` about how to use it. note that there is a number of known bugs in rpctrace, for which zhengda has sent patches... though I haven't reviewed all of them I think there are some nasty Mach operations that are really hard to proxy -- but I don't think the auth mechanism needs any of these... +* IRC, freenode, #hurd, 2011-11-04 + + [[!taglink open_issue_documentation]] + + hello. Are there any documentation about understanding output + of rpctrace? + no + you should read the source code, best doc available + if you have too many numbers and almost no symbolc names, + you're lacking rpc definition lists + check that the gnumach-common package is installed, as it + provides the gnumach definitions + (the glibc ones are almost always available) + with those two, you should be fine for the beginning + gnumach-common is installed. And what is the name for glibc + package for gnumach definitions. + Also I'm using libraries specified by LD_LIBRARY_PATH. Does it + make influence on absence of symbolic names? + no + rpctrace --help + see the --rpc-list=FILE option + the default lists are in /usr/share/msgids/, with the .msgids + extension + $ dpkg -S msgids + gnumach-common: /usr/share/msgids/gnumach.msgids + hurd: /usr/share/msgids/hurd.msgids + ok, glibc has none, it's the hurd + for more details about the output, read the source code + it shouldn't be that hard to grasp + -I /usr/share/msgids helped + thank you + it shouldn't have, it's the default path + but symbolic names appeared + well, that's weird :) + braunr: the output of rpctrace --help should tell the + default dir for msgids + # See Also diff --git a/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn b/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn index a9317c21..5228515f 100644 --- a/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn +++ b/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn @@ -233,3 +233,40 @@ See also: [[open_issues/resource_management_problems/pagers]]. I have never looked at it. [[open_issues/mach-defpager_vs_defpager]]. + + +# IRC, freenode, #hurd, 2011-11-08 + + who else uses defpager besides tmpfs and kernel? + normally, nothing directly + than why tmpfs should use defpager? + it's its backend + backign store rather + the backing store of most file systems are partitions + tmpfs has none, it uses the swap space + if we allocate memory for tmpfs using vm_allocate, will it be able + to use swap partition? + it should + vm_allocate just maps anonymous memory + anonymous memory uses swap space as its backing store too + but be aware that this part of the vm system is known to have + deficiencies + which is why all mach based implementations have rewritten their + default pager + what kind of deficiencies? + bugs + and design issues, making anonymous memory fragmentation horrible + mcsim: vm_allocate doesn't return a memory object; so it can't be + passed to clients for mmap() + antrik: I use vm_allocate in pager_read_page + mcsim: well, that means that you have to actually implement a + pager yourself + also, when the kernel asks the pager to write back some pages, it + expects the memory to become free. if you are "paging" to ordinary + anonymous memory, this doesn't happen; so I expect it to have a very bad + effect on system performance + both can be avoided by just passing a real anonymous memory + object, i.e. one provided by the defpager + only problem is that the current defpager implementation can't + really handle that... + at least that's my understanding of the situation diff --git a/hurd/virtual_file_system/discussion.mdwn b/hurd/virtual_file_system/discussion.mdwn new file mode 100644 index 00000000..9e12d01e --- /dev/null +++ b/hurd/virtual_file_system/discussion.mdwn @@ -0,0 +1,39 @@ +[[!meta copyright="Copyright © 2011 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_documentation]] + +IRC, freenode, #hurd, 2011-11-12: + + So hurd implements a 'transparent translator' somewhere which + just passes all IO calls to the posix IO I'm used to? (i.e. read, write, + open, close, etc.?) + it's the normal way of operation + glibc's read() doesn't do a system call, it always does an RPC to + the underlying translator + be it ext2fs for /, or your foobarfs for your node + Ok that makes sense. How does one program know which translator + it should refer to though? + the read() call magically knows which process to invoke? + the / translator is always known + and then you ask /'s translator about /home, then /home/you, then + /home/you/foobar + it tells you which other translator tyou have to contact + that's on open + It's a tree! Ok. + the notion of fd is then simply knowing the translator + Right. 'file descriptor' is now 'translator address descriptor' + maybe. + it's glibc which knows about FDs, nothing else knows + yes + actually an RPC port, simply + I want to try out the new RPC mechanism that mach implements + err, which "new" RPC ? + mach's RPCs are very old actually :) -- cgit v1.2.3