summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--contributing/web_pages.mdwn21
-rw-r--r--contributing/web_pages/news/moth_next.mdwn88
-rw-r--r--open_issues/dde.mdwn23
-rw-r--r--open_issues/dde/13778443
-rw-r--r--open_issues/libpthread_pthread_key_create_reuse.mdwn82
-rw-r--r--open_issues/libpthread_pthread_key_create_reuse/pthread_key_create_reuse.c48
-rw-r--r--open_issues/performance/io_system/binutils_ld_64ksec.mdwn23
-rw-r--r--open_issues/xen_lseek.mdwn22
-rw-r--r--open_issues/xen_lseek/test-lseek.c (renamed from open_issues/performance/io_system/test-lseek.c)0
-rw-r--r--open_issues/xen_lseek/test-mach.c (renamed from open_issues/performance/io_system/test-mach.c)0
-rw-r--r--public_hurd_boxen.mdwn30
-rw-r--r--public_hurd_boxen/sceen.mdwn11
-rw-r--r--user/Maksym_Planeta.mdwn135
-rw-r--r--user/musial.mdwn19
14 files changed, 290 insertions, 255 deletions
diff --git a/contributing/web_pages.mdwn b/contributing/web_pages.mdwn
index d1b3c0fc..b2e96121 100644
--- a/contributing/web_pages.mdwn
+++ b/contributing/web_pages.mdwn
@@ -130,13 +130,22 @@ is also read-only.
$ git clone http://www.bddebian.com:8888/git/hurd-web [dest]
-For all cases: if you omit `[dest]` it will default to `hurd-web`.
+Or, you can check out the Savannah repository:
-Later, you can just `cd` into the `hurd-web` directory and run a `git pull` to
-get hold of the latest changes others have been installing in the mean time.
-(In most cases, you should use `git pull --rebase`,
-to avoid useless *Merge branch ...* messages. See the
-Git documentation for details.)
+ $ git clone git://git.savannah.gnu.org/hurd/web.git [dest]
+
+See <http://git.savannah.gnu.org/cgit/hurd/web.git>. If you're using the `ssh`
+protocol, and you're a member of the Hurd's [[rules/Savannah_group]], you can
+also push to this repository. The disadvantage of pushing to the Savannah
+repository is that there is no [[ikiwiki]] installation where the pushed
+changes are immediatelly rendered and viewable by everyone.
+
+For all cases: if you omit `[dest]` it will default to `hurd-web` for the
+`bddebian.com` repositories, or `web` for a Savannah clone.
+
+Later, you can just `cd` into the `hurd-web` or `web` directory, and, for
+example, run `git pull` to get hold of the latest changes others have been
+installing in the mean time.
## Editing the Content
diff --git a/contributing/web_pages/news/moth_next.mdwn b/contributing/web_pages/news/moth_next.mdwn
index 2555cd73..cd03a366 100644
--- a/contributing/web_pages/news/moth_next.mdwn
+++ b/contributing/web_pages/news/moth_next.mdwn
@@ -25,7 +25,7 @@ else="
<!--basic structure of a MotH entry. Adapt, reduce and add points as needed. At the end, try to make the text flow as a unified whole.-->
-This month [hurd hacker] [item]
+In the third quarter of 2011, the [hurd hacker] [item]
Also …
@@ -43,27 +43,69 @@ And …
* [[toolchain/ELFOSABI_GNU]]
- * [Arch Hurd, DDE](http://www.archhurd.org/news/22/)
-
- * Arch Hurd will have a booth at [FrOSCon](http://www.froscon.org/).
-
- * Bits from the Debian GNU/Hurd porters,
- id:"20110721172827.GF4057@const.famille.thibault.fr",
- <http://lists.debian.org/debian-devel-announce/2011/07/msg00002.html>
-
- * [[2011-q2-ps]]
-
- * GSoC end
-
- * mcsim memory allocator project
-
- * GHM.
-
- * <http://audio-video.gnu.org/video/ghm2011/>; Samuel. Slides. Also add
- all to media.
-
- * Richard's new buildd.
-
- Is this for Q4?
+ * The Arch Hurd Hackers [packaged DDE](http://www.archhurd.org/news/22/), so
+ Linux 2.6 drivers can now be compiled on Arch Hurd to run in
+ userspace. At the time of writing it supports network cards, while
+ other driver-types still need their interfaces ported.
+
+ * Also they had
+ [a booth at FrOSCon](http://www.froscon.de/aussteller/projekt) and
+ [released a new Arch Hurd LiveCD](http://www.archhurd.org/news/24/),
+ so new users can easily test the current state of the Arch flavor
+ of the Hurd.
+
+ * The videos and slides from the GNU Hacker Meeting 2011 in Paris
+ are [online](http://www.gnu.org/ghm/2011/paris/), including the
+ talk from Samuel Thibault:
+ [GNU/Hurd, aka. Extensibility from the Ground](http://audio-video.gnu.org/video/ghm2011/Samuel_Thibault-GNU_Hurd.ogv)
+ ([slides](http://www.gnu.org/ghm/2011/paris/slides/samuel-thibault-hurd.pdf)). He
+ explains nicely how the simple concept of translators gives power
+ to non-priviledged and casual users (once we get some of those :)
+ ) without security implications, and how Sub-Hurds and
+ Neighbor-Hurds compare to Linux containers.
+
+ “It’s all about freedom #0”
+
+ * Samuel Thibault wrote a new
+ [Bits from the Debian GNU/Hurd porters](http://lists.debian.org/debian-devel-announce/2011/07/msg00002.html)
+
+ * Thomas Schwinge improved the technical documentation of the
+ [[hurd/io_path]] in translators to make it easier for new developers to start hacking.
+
+ * Guillem Jover, Fridolin Pokorny and Jonathan Neuschäfer
+ [sent](http://lists.gnu.org/bug-hurd/2011-08/msg00184.html)
+ [many](http://lists.gnu.org/bug-hurd/2011-08/msg00093.html)
+ [patches](http://lists.gnu.org/bug-hurd/2011-08/msg00030.html) for
+ gnumach, improving stability, fixing memory leaks and cleaning up
+ code.
+
+ * Jeremie Koenig finished his Google Summer of Code project to
+ [Improve Java on Hurd](http://www.gnu.org/software/hurd/user/jkoenig/java.html). He
+ [improved the Hurd signalling](http://lists.gnu.org/bug-hurd/2011-06/msg00073.html),
+ ported OpenJDK and created a
+ [Java Hurd-Library](https://github.com/jeremie-koenig/hurd-java)
+ which already allows writing a
+ [Hello World translator in Java](https://github.com/jeremie-koenig/hurd-java/blob/master/HelloMach.java),
+ though still pretty low-level.
+
+ * Maksym Planeta replaced GNUmach’s old zalloc memory allocator with
+ the new balloc from Richard Braun
+ ([integration commit](http://git.savannah.gnu.org/cgit/hurd/gnumach.git/commit/?id=50d073c5ef0feb1676606d0068abf626e8297cd7)),
+ which handles slabs and should waste less memory than zalloc. Also
+ balloc has a cpu cache level, so it should work faster on SMP
+ systems, once we get up do date SMP CPU drivers for GNUmach.
+
+ * 69.96% of debian packages
+ [are now available for the Hurd](https://buildd.debian.org/stats/graph-big.png),
+ so we’re getting closer to the goal of reaching 85%. If you can
+ port debian packages and want to help the Hurd, this is the
+ perfect time to get in contact and
+ [port your favorite missing package](http://www.debian.org/ports/hurd/hurd-devel-debian)
+ to the Hurd.
+
+ * And Richard Braun contributed a new
+ [[buildd,_porterbox_and_public_box|public_hurd_boxen]] via
+ sceen.net, making it easier to test the Hurd without much setup as
+ well as improving debian packaging.
"""]]
diff --git a/open_issues/dde.mdwn b/open_issues/dde.mdwn
index 9e2ec742..e2cff94f 100644
--- a/open_issues/dde.mdwn
+++ b/open_issues/dde.mdwn
@@ -8,25 +8,8 @@ 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]]."]]"""]]
-[[General Information|/dde]].
-
-
-# IRC, freenode, #hurd, 2011-10-18
+[[!tag open_issue_hurd open_issue_gnumach]]
-[[!tag open_issue_hurd]]
-
- [DDE crash, or similar]
- <youpi> it's fake_local_irq_disable_flags(), then raw_local_irq_disable(),
- then raw_local_irq_restore(), which *does not* release the cli_lock
- <youpi> the "prove it" comment is (as I expected) completely wrong
- <youpi> npnth: http://paste.debian.net/137784/
-
-[[137784]]
+[[General Information|/dde]].
- <youpi> could you try this patch ?
- <youpi> (I've not even tried to build it)
- <npnth> youpi: speaking of which, it still seems to hang :/ I'll 1) double
- check it applied correctly and 2) get a gdb output if it did
- <youpi> npnth: could you add printing the value of unlock_refcnt?
- <youpi> so we can check what's happening
- <npnth> unlock_refcnt is at 0, interesting
+Still waiting for interface finalization and proper integration.
diff --git a/open_issues/dde/137784 b/open_issues/dde/137784
deleted file mode 100644
index 1529465b..00000000
--- a/open_issues/dde/137784
+++ /dev/null
@@ -1,43 +0,0 @@
-diff --git a/libdde_linux26/lib/src/arch/l4/cli_sti.c b/libdde_linux26/lib/src/arch/l4/cli_sti.c
-index 051f259..6a8c460 100644
---- a/libdde_linux26/lib/src/arch/l4/cli_sti.c
-+++ b/libdde_linux26/lib/src/arch/l4/cli_sti.c
-@@ -4,6 +4,8 @@
-
- /* IRQ lock reference counter */
- static atomic_t _refcnt = ATOMIC_INIT(0);
-+/* Refcnt value at which unlocking the cli_lock (it's not always 0) */
-+static int unlock_refcnt;
- static ddekit_lock_t cli_lock;
-
- /* Check whether IRQs are currently disabled.
-@@ -57,9 +59,6 @@ void fake_local_irq_restore(unsigned long flags)
- /* Store the current flags state.
- *
- * This is done by returning the current refcnt.
-- *
-- * XXX: Up to now, flags was always 0 at this point and
-- * I assume that this is always the case. Prove?
- */
- unsigned long __raw_local_save_flags(void)
- {
-@@ -82,7 +81,7 @@ void raw_local_irq_restore(unsigned long flags)
- {
- Assert(cli_lock != NULL);
- atomic_set(&_refcnt, flags);
-- if (flags == 0)
-+ if (flags == unlock_refcnt)
- ddekit_lock_unlock(&cli_lock);
- }
-
-@@ -95,7 +94,9 @@ void raw_local_irq_disable(void)
- if (cli_lock == NULL)
- ddekit_lock_init_unlocked(&cli_lock);
-
-- nested_lock(cli_lock);
-+ if (nested_lock(cli_lock))
-+ /* Tell the corresponding restorer to release cli_lock */
-+ unlock_refcnt = atomic_read(&_refcnt);
- atomic_inc(&_refcnt);
- }
-
diff --git a/open_issues/libpthread_pthread_key_create_reuse.mdwn b/open_issues/libpthread_pthread_key_create_reuse.mdwn
deleted file mode 100644
index ca2da2f5..00000000
--- a/open_issues/libpthread_pthread_key_create_reuse.mdwn
+++ /dev/null
@@ -1,82 +0,0 @@
-[[!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]]."]]"""]]
-
-[[!meta title="libpthread: pthread_key_create, reuse"]]
-
-[[!tag open_issue_libpthread]]
-
-IRC, FreeNode, #hurd, 2011-07-02:
-
- < pinotree> hm, maybe i found a libpthread bug
- * pinotree tries a testcase
- < pinotree> yesssss, found the bug :)
- < pinotree> youpi: it's a problem of the key reuse in pthread_key_create()
- < youpi> it doesn't reset it?
- < youpi> were you looking at the licq issue?
- < pinotree> no, gtest
- < youpi> k
- < youpi> licq has a failing threadspecific issue
- < youpi> [ FAILED ] ThreadSpecificData.dataDeletedWhenThreadExits
- < pinotree> basically, pthread_key_delete() does not delete the key values
- from the "thread_specifics" ihash
- < pinotree> but those were new keys, so i'm not sure it is allowed to
- return values of previous keys?
- < pinotree> after all, the actual key value is an implementation detail,
- applications shouldn't care about it being reused
- < pinotree> (imho)
- < youpi> Upon key creation, the value NULL shall be associated with the new
- key in all active threads.
- < youpi> ok, so we have to clear it in all threads
- < youpi> that's a pity
- < pinotree> or just remove the entry from the hash on key removal
- < youpi> pinotree: from all the hashes, you mean?
- < pinotree> youpi: from how i see it, adding a snippet like
- http://paste.debian.net/121690/ in pthread_key_delete() should do the job
- < youpi> that only drops from the current thread
- < pinotree> ah hm, other threads
- < youpi> we need to drop from all threads
- < youpi> that's the pity part
- < pinotree> youpi: the licq case could look like a similar issue, at a
- veeery quick glance
-
-Test program: [[pthread_key_create_reuse.c]]
-
-
-2011-11-01:
-
- <pinotree> youpi: about the bug with pthread keys (reuse): would be an
- acceptable solution having a mutex for the thread_specifics of each
- thread?
- <youpi> you mean one per thread, one global, or one per key, or ?
- <youpi> what is it supposed to protect?
- <pinotree> the thread_specifics of each thread
- <youpi> pinotree: but against what?
- <pinotree> the idea would be: when destroying a key, iterate over all the
- exiting threads and remove the key data from the thread_specifics of each
- thread
- <youpi> one of the issue is getting to browse through the whole list of
- threads
- <youpi> the other is concurrency between that, and a thread dying
- <pinotree> there's the __pthread_threads_lock rwlock
- <youpi> it should be enough to keep it locked during the iteration
- <pinotree> but that wouldn't be enough when one thread is destroying a key,
- and another one is doing {get,set}specific() on that key
- <youpi> that's not supposed to happen
- <pinotree> mmm
- <youpi> “The effect of calling pthread_getspecific() or
- pthread_setspecific() with a key value not obtained from
- pthread_key_create() or after key has been deleted with
- pthread_key_delete() is undefined.”
- <youpi> undefined -> you are allowed to just blow up
- <pinotree> but it's not been deleted yet... :)
- <youpi> it could be, just a matter of time
- <youpi> you're not supposed to rely on time-luckyness :)
- <pinotree> mmm
- <pinotree> bah, you've convinced me ( :) )
diff --git a/open_issues/libpthread_pthread_key_create_reuse/pthread_key_create_reuse.c b/open_issues/libpthread_pthread_key_create_reuse/pthread_key_create_reuse.c
deleted file mode 100644
index f7f5874e..00000000
--- a/open_issues/libpthread_pthread_key_create_reuse/pthread_key_create_reuse.c
+++ /dev/null
@@ -1,48 +0,0 @@
-#include <pthread.h>
-#include <stdio.h>
-#include <assert.h>
-
-#define DEBUG
-
-void del(void *x __attribute__((unused)))
-{
-}
-
-void work(int val)
-{
- pthread_key_t key1;
- pthread_key_t key2;
-
-#ifdef DEBUG
- printf("work/%d: start\n", val);
-#endif
- assert(pthread_key_create(&key1, &del) == 0);
- assert(pthread_key_create(&key2, &del) == 0);
-#ifdef DEBUG
- printf("work/%d: pre-setspecific: %p,%p\n", val, pthread_getspecific(key1), pthread_getspecific(key2));
-#else
- assert(pthread_getspecific(key1) == NULL);
- assert(pthread_getspecific(key2) == NULL);
-#endif
- assert(pthread_setspecific(key1, (void *)(0x100 + val)) == 0);
- assert(pthread_setspecific(key2, (void *)(0x200 + val)) == 0);
-#ifdef DEBUG
- printf("work/%d: post-setspecific: %p,%p\n", val, pthread_getspecific(key1), pthread_getspecific(key2));
-#else
- assert(pthread_getspecific(key1) == (void *)(0x100 + val));
- assert(pthread_getspecific(key2) == (void *)(0x200 + val));
-#endif
- assert(pthread_key_delete(key1) == 0);
- assert(pthread_key_delete(key2) == 0);
-}
-
-int main()
-{
- int i;
-
- for (i = 0; i < 8; ++i) {
- work(i + 1);
- }
-
- return 0;
-}
diff --git a/open_issues/performance/io_system/binutils_ld_64ksec.mdwn b/open_issues/performance/io_system/binutils_ld_64ksec.mdwn
index d0b8ea7f..931fd0ee 100644
--- a/open_issues/performance/io_system/binutils_ld_64ksec.mdwn
+++ b/open_issues/performance/io_system/binutils_ld_64ksec.mdwn
@@ -27,10 +27,6 @@ extracted from cdf7c161ebd4a934c9e705d33f5247fd52975612 sources, 2010-10-24.
On the idle grubber, this one repeatedly takes a few minutes wall time to
complete successfully, contrary to a few seconds on a GNU/Linux system.
-> On order of slowness may in fact be due to a Xen-specific issue, see
-> [[xen_lseek]]. (But there are probably still one or two orders left, even
-> without Xen.)
-
While processing the object files, there is heavy interaction with the relevant
[[hurd/translator/ext2fs]] process. Running [[hurd/debugging/rpctrace]] on
the testee shows that (primarily) an ever-repeating series of `io_seek` and
@@ -38,19 +34,6 @@ the testee shows that (primarily) an ever-repeating series of `io_seek` and
shows the equivalent thing (`_llseek`, `read`) -- but Linux' I/O system isn't
as slow as the Hurd's.
----
-
-IRC, freenode, #hurd, 2011-09-01:
-
- <youpi> hum, f951 does myriads of 71->io_seek_request (32768 0) = 0 32768
- <youpi> no wonder it's slow
- <youpi> unfortunately that's also what it does on linux, the system call is
- just less costly
- <youpi> apparently gfortran calls io_seek for, like, every token of the
- sourced file
- <youpi> (fgetpos actually, but that's the same)
- <youpi> and it is indeed about 10 times slower under Xen for some reason
-
-Also see testcase [[test-lseek.c]] and [[test-mach.c]]
-
-[[!tag open_issue_xen]]
+As Samuel figured out later, this slowness may in fact be due to a Xen-specific
+issue, see [[Xen_lseek]]. After the latter has been addressed, we can
+re-evaluate this issue here.
diff --git a/open_issues/xen_lseek.mdwn b/open_issues/xen_lseek.mdwn
index accc7c8f..756abf5e 100644
--- a/open_issues/xen_lseek.mdwn
+++ b/open_issues/xen_lseek.mdwn
@@ -10,6 +10,17 @@ License|/fdl]]."]]"""]]
[[!tag open_issue_xen]]
+IRC, freenode, #hurd, 2011-09-01:
+
+ <youpi> hum, f951 does myriads of 71->io_seek_request (32768 0) = 0 32768
+ <youpi> no wonder it's slow
+ <youpi> unfortunately that's also what it does on linux, the system call is
+ just less costly
+ <youpi> apparently gfortran calls io_seek for, like, every token of the
+ sourced file
+ <youpi> (fgetpos actually, but that's the same)
+ <youpi> and it is indeed about 10 times slower under Xen for some reason
+
IRC, freenode, #hurd, 2011-11-02:
<youpi> btw, we have a performance issue with xen
@@ -33,3 +44,14 @@ IRC, freenode, #hurd, 2011-11-02:
http://www.gnu.org/software/hurd/open_issues/performance/io_system/binutils_ld_64ksec.html
[[performance/io_system/binutils_ld_64ksec]].
+
+Also see the simple testcases [[test-lseek.c]] and [[test-mach.c]].
+
+IRC, freenode, #hurd, 2011-11-05:
+
+ <youpi> [test-mach.c is] mostly as a reference for the trap overhead
+ <youpi> 0.56µs (xen) vs 0.48µs(kvm) on test-mach
+ <youpi> 455µs(xen) vs 16µs(kvm) on test-lseek
+ <youpi> that might simply be an issue in the RPC mechanism, which behaves
+ badly with the xen memory management
+ <youpi> yes, about 0.5ms for an lseek, that's quite high :)
diff --git a/open_issues/performance/io_system/test-lseek.c b/open_issues/xen_lseek/test-lseek.c
index 667dce66..667dce66 100644
--- a/open_issues/performance/io_system/test-lseek.c
+++ b/open_issues/xen_lseek/test-lseek.c
diff --git a/open_issues/performance/io_system/test-mach.c b/open_issues/xen_lseek/test-mach.c
index 90337346..90337346 100644
--- a/open_issues/performance/io_system/test-mach.c
+++ b/open_issues/xen_lseek/test-mach.c
diff --git a/public_hurd_boxen.mdwn b/public_hurd_boxen.mdwn
index 5a281368..6bce8ffb 100644
--- a/public_hurd_boxen.mdwn
+++ b/public_hurd_boxen.mdwn
@@ -28,10 +28,14 @@ image|hurd/running/qemu]].
"[[bddebian]]","goober","Debian GNU/Hurd","?"
"[[bddebian]]","grubber","Debian GNU/Hurd","Celeron 2.2 GHz; 554 MiB","Xen domU on [[zenhost]]; for experimental stuff"
"[[bddebian]]","[[zenhost]]","Debian GNU/Linux","Celeron 2.2 GHz","Xen dom0 for several hosts"
+"[[sceen]]","darnassus","Debian GNU/Hurd","Core i5 3.1 GHz, 1.8 GiB","KVM guest on shattrath; public Hurd box"
+"[[sceen]]","ironforge","Debian GNU/Hurd","Core i5 3.1 GHz, 1.8 GiB","KVM guest on shattrath; Debian buildd"
+"[[sceen]]","exodar","Debian GNU/Hurd","Core i5 3.1 GHz, 1.8 GiB","KVM guest on shattrath; Debian porterbox"
+"[[sceen]]","shattrath","Debian GNU/Linux","Core i5 3.1 GHz","KVM host"
"Debian","[strauss.debian.net](http://strauss.debian.net/ssh)","Debian GNU/Hurd",,"all Debian Developers have access"
"""]]
-To request an account on the *[[bddebian]]* machines either contact
+To request an account on the *[[bddebian]]* or *[[sceen]]* machines, either contact
*tschwinge* (other people might also be able to help) in [[IRC]]
or send email to <hurd-shell-account@gnu.org> (please include your desired user
name and public SSH key). Also use these contact
@@ -41,14 +45,11 @@ addresses for requesting support with respect to software installations, etc.
For easy access, you should append your public SSH key(s)
to `~/.ssh/authorized_keys` on the remote machine.
-Also, add the [[!toggle id=bddebian_ssh_config text="following stanza (click
-here to toggle display)"]] to the `~/.ssh/config` file of the machine you're
-connecting from.
-
-[[!toggleable id=bddebian_ssh_config text="""
+Also, add the following stanza to the `~/.ssh/config` file of the machine
+you're connecting from.
# Stanza from <http://www.gnu.org/software/hurd/public_hurd_boxen.html>,
- # 2010-12-15.
+ # 2011-11-06.
Host blubber.bddebian.com blubber
HostName blubber.bddebian.com
@@ -80,13 +81,16 @@ connecting from.
Port 2260
Host blubber.bddebian.com blubber grubber.bddebian.com grubber snubber.bddebian.com snubber
- ProxyCommand ssh zenhost socat - TCP4:%h:%p
+ # Tunnel through zenhost.
+ ProxyCommand ssh zenhost exec socat - TCP4:%h:%p
Host *.bddebian.com blubber clubber flubber gnubber goober grubber snubber zenhost
+ # Don't worry about the IP address (dial-up connection).
CheckHostIP no
User [user name]
-
-The `CheckHostIP` statement is for not having to worry about the machines's IP
-addresses changing (due to being behind a dial-up connection).
-
-"""]]
+
+ Host darnassus.sceen.net darnassus
+ HostName darnassus.sceen.net
+
+ Host *.sceen.net darnassus
+ User [user name]
diff --git a/public_hurd_boxen/sceen.mdwn b/public_hurd_boxen/sceen.mdwn
new file mode 100644
index 00000000..25416857
--- /dev/null
+++ b/public_hurd_boxen/sceen.mdwn
@@ -0,0 +1,11 @@
+[[!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]]."]]"""]]
+
+<http://www.sceen.net/>
diff --git a/user/Maksym_Planeta.mdwn b/user/Maksym_Planeta.mdwn
new file mode 100644
index 00000000..c44a4fcb
--- /dev/null
+++ b/user/Maksym_Planeta.mdwn
@@ -0,0 +1,135 @@
+[[!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]]."]]"""]]
+
+[[!toc]]
+#Notes on tmpfs
+
+## mach-defpager
+
+[[defpager|http://www.bddebian.com:8888/~hurd-web/user/Maksym_Planeta/#defpager81111]]
+
+[[http://www.mail-archive.com/bug-hurd@gnu.org/msg18859.html]]
+
+## Steps
+
+1. Find out what causes crashes in tmpfs with defpager
+
+[[http://www.gnu.org/s/hurd/hurd/translator/tmpfs/notes_various.html]]
+
+TODO: Consider deleting of parameter "port" in function mach-defpager/default_pager.c:pager_port_list_insert
+since this parameter is unused
+
+2. Write own pager
+
+ 6.11.11 Reading/writing for files that fit in vm_page_size works
+
+ 7.11.11 Works for any size.
+
+3. Make links work
+
+ Symlinks behavior: [[links|http://www.bddebian.com:8888/~hurd-web/user/Maksym_Planeta/#links81111]]
+
+ 8.11.11 Symlinks work.
+
+4. Control of used space by tmpfs.
+
+ TODO: Make tmpfs use not more space than it was allowed.
+
+5. Thread safety.
+
+ TODO: During execution tmpfs hangs in random places. The most possible is variant is deadlocks,
+ because nothing was undertaken for thread safety.
+
+6. After sometime of inactivity tmpfs exits.
+
+ TODO: Find out why and correct this.
+
+#Debugging
+
+To debug tmpfs, using libraries from "$PWD"/lib and trace rpc:
+
+ settrans -ca foo /usr/bin/env LD_LIBRARY_PATH="$PWD"/lib utils/rpctrace -I /usr/share/msgids/ tmpfs/tmpfs 1M
+ LD_LIBRARY_PATH="$PWD"/lib gdb tmpfs/tmpfs `pidof tmpfs`
+
+For debugging ext2fs:
+
+ settrans --create --active ramdisk0 /hurd/storeio -T copy zero:32M && \
+ /sbin/mkfs.ext2 -F -b 4096 ramdisk0 && \
+ settrans --active --orphan ramdisk0 /usr/bin/env LD_LIBRARY_PATH="$PWD"/lib utils/rpctrace -I /usr/share/msgids/ \
+ ext2fs/ext2fs.static ramdisk0
+
+#Questions
+
+1. What are sequence numbers? What are they used for?
+2. Is there any way to debug mach-defpager? When I set breakpoint to any function in it, pager never breaks.
+
+#Conversations
+
+## 8.11.11
+
+### links<a id="links81111"/>
+ (10:29:11) braunr: mcsim: ln -s foo/bar foo/baz means the link name is baz in the foo directory,
+ and its target (relative to its directory) is foo/bar (which would mean /tmp/foo/foo/bar in canonical form)
+ (10:29:42) braunr: youpi: tschwinge: what did ludovic achieve ?
+ (10:30:06) tschwinge: mcsim: As Richard says, symlink targets are always relative to the directory they're contained in.
+ (10:30:51) tschwinge: braunr: This Hydra/Nix (I wtill mix it all up) thing is kind of a package managing system.
+ (10:31:17) tschwinge: He has written scripts for bootstrapping a Hurd toolchain.
+ (10:31:26) braunr: oh ok
+ (10:31:27) mcsim: so, if I want to create link in cd, first I need to cd there?
+ (10:31:28) tschwinge: And then uses that to build a whole bootable image.
+ (10:31:36) mcsim: in foo*
+ (10:31:36) braunr: mcsim: just provide the right paths
+ (10:32:11) braunr: $ touch foo/bar
+ (10:32:14) braunr: $ ln -s bar foo/baz
+ (10:32:32) braunr: bar
+ (10:32:35) braunr: baz -> bar
+
+### defpager<a id="defpager81111"/>
+
+ earlier:
+ <tschwinge>: 1. On every system there is a ``default pager'' (mach-defpager). That one is responsible
+ for all ``anonymous memory''. For example, when you do malloc(10 MiB), and then there is memory pressure,
+ this 10 MiB memory region is backed by the default pager, whose job then is it to provide the backing store for this.
+ <tschwinge>: This is what commonly would be known as a swap partition.
+ <tschwinge>: And this is also the way tmpfs works (as I understand it).
+ <tschwinge>: malloc(10 MiB) can also be mmap(MAP_ANONYMOUS, 10 MIB); that's the same, essentially.
+ <tschwinge>: Now, for ext2fs or any other disk-based file system, this is different:
+ <tschwinge>: The ext2fs translator implements its own backing store, namely it accesses the disk for storing
+ changed file content, or to read in data from disk if a new file is opened.
+
+ ...
+
+ (10:36:14) mcsim: who else uses defpager besides tmpfs and kernel?
+ (10:36:27) braunr: normally, nothing directly
+ (10:37:04) mcsim: than why tmpfs should use defpager?
+ (10:37:22) braunr: it's its backend
+ (10:37:28) braunr: backign store rather
+ (10:37:38) braunr: the backing store of most file systems are partitions
+ (10:37:44) braunr: tmpfs has none, it uses the swap space
+ (10:39:31) mcsim: if we allocate memory for tmpfs using vm_allocate, will it be able to use swap partition?
+ (10:39:56) braunr: it should
+ (10:40:27) braunr: vm_allocate just maps anonymous memory
+ (10:41:27) braunr: anonymous memory uses swap space as its backing store too
+ (10:43:47) braunr: but be aware that this part of the vm system is known to have deficiencies
+ (10:44:14) braunr: which is why all mach based implementations have rewritten their default pager
+ (10:45:11) mcsim: what kind of deficiencies?
+ (10:45:16) braunr: bugs
+ (10:45:39) braunr: and design issues, making anonymous memory fragmentation horrible
+
+ ...
+
+ (15:23:33) antrik: mcsim: vm_allocate doesn't return a memory object; so it can't be passed to clients for mmap()
+ (15:50:37) mcsim: antrik: I use vm_allocate in pager_read_page
+ (15:54:43) antrik: mcsim: well, that means that you have to actually implement a pager yourself
+ (15:56:10) 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
+ (15:56:54) antrik: both can be avoided by just passing a real anonymous memory object, i.e. one provided by the defpager
+ (15:57:07) antrik: only problem is that the current defpager implementation can't really handle that...
diff --git a/user/musial.mdwn b/user/musial.mdwn
new file mode 100644
index 00000000..24a526be
--- /dev/null
+++ b/user/musial.mdwn
@@ -0,0 +1,19 @@
+[[!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]]."]]"""]]
+
+Robert Musial
+
+Cleveland, OH
+
+musial [at] gnu [dot] org
+
+http://musial.sdf.org
+
+http://github.com/musial