summaryrefslogtreecommitdiff
path: root/hurd
diff options
context:
space:
mode:
Diffstat (limited to 'hurd')
-rw-r--r--hurd/debugging/rpctrace.mdwn37
-rw-r--r--hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn37
-rw-r--r--hurd/virtual_file_system/discussion.mdwn39
3 files changed, 113 insertions, 0 deletions
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.
<antrik> 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
<antrik> 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]]
+
+ <mcsim> hello. Are there any documentation about understanding output
+ of rpctrace?
+ <braunr> no
+ <braunr> you should read the source code, best doc available
+ <braunr> if you have too many numbers and almost no symbolc names,
+ you're lacking rpc definition lists
+ <braunr> check that the gnumach-common package is installed, as it
+ provides the gnumach definitions
+ <braunr> (the glibc ones are almost always available)
+ <braunr> with those two, you should be fine for the beginning
+ <mcsim> gnumach-common is installed. And what is the name for glibc
+ package for gnumach definitions.
+ <mcsim> Also I'm using libraries specified by LD_LIBRARY_PATH. Does it
+ make influence on absence of symbolic names?
+ <braunr> no
+ <braunr> rpctrace --help
+ <braunr> see the --rpc-list=FILE option
+ <braunr> the default lists are in /usr/share/msgids/, with the .msgids
+ extension
+ <braunr> $ dpkg -S msgids
+ <braunr> gnumach-common: /usr/share/msgids/gnumach.msgids
+ <braunr> hurd: /usr/share/msgids/hurd.msgids
+ <braunr> ok, glibc has none, it's the hurd
+ <braunr> for more details about the output, read the source code
+ <braunr> it shouldn't be that hard to grasp
+ <mcsim> -I /usr/share/msgids helped
+ <mcsim> thank you
+ <braunr> it shouldn't have, it's the default path
+ <mcsim> but symbolic names appeared
+ <braunr> well, that's weird :)
+ <pinotree> 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
+
+ <mcsim> who else uses defpager besides tmpfs and kernel?
+ <braunr> normally, nothing directly
+ <mcsim> than why tmpfs should use defpager?
+ <braunr> it's its backend
+ <braunr> backign store rather
+ <braunr> the backing store of most file systems are partitions
+ <braunr> tmpfs has none, it uses the swap space
+ <mcsim> if we allocate memory for tmpfs using vm_allocate, will it be able
+ to use swap partition?
+ <braunr> it should
+ <braunr> vm_allocate just maps anonymous memory
+ <braunr> anonymous memory uses swap space as its backing store too
+ <braunr> but be aware that this part of the vm system is known to have
+ deficiencies
+ <braunr> which is why all mach based implementations have rewritten their
+ default pager
+ <mcsim> what kind of deficiencies?
+ <braunr> bugs
+ <braunr> and design issues, making anonymous memory fragmentation horrible
+ <antrik> mcsim: vm_allocate doesn't return a memory object; so it can't be
+ passed to clients for mmap()
+ <mcsim> antrik: I use vm_allocate in pager_read_page
+ <antrik> mcsim: well, that means that you have to actually implement a
+ pager yourself
+ <antrik> 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
+ <antrik> both can be avoided by just passing a real anonymous memory
+ object, i.e. one provided by the defpager
+ <antrik> only problem is that the current defpager implementation can't
+ really handle that...
+ <antrik> 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:
+
+ <sea4ever> 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.?)
+ <youpi> it's the normal way of operation
+ <youpi> glibc's read() doesn't do a system call, it always does an RPC to
+ the underlying translator
+ <youpi> be it ext2fs for /, or your foobarfs for your node
+ <sea4ever> Ok that makes sense. How does one program know which translator
+ it should refer to though?
+ <sea4ever> the read() call magically knows which process to invoke?
+ <youpi> the / translator is always known
+ <youpi> and then you ask /'s translator about /home, then /home/you, then
+ /home/you/foobar
+ <youpi> it tells you which other translator tyou have to contact
+ <youpi> that's on open
+ <sea4ever> It's a tree! Ok.
+ <youpi> the notion of fd is then simply knowing the translator
+ <sea4ever> Right. 'file descriptor' is now 'translator address descriptor'
+ maybe.
+ <youpi> it's glibc which knows about FDs, nothing else knows
+ <youpi> yes
+ <youpi> actually an RPC port, simply
+ <sea4ever> I want to try out the new RPC mechanism that mach implements
+ <youpi> err, which "new" RPC ?
+ <youpi> mach's RPCs are very old actually :)