diff options
-rw-r--r-- | contributing/web_pages.mdwn | 21 | ||||
-rw-r--r-- | contributing/web_pages/news/moth_next.mdwn | 88 | ||||
-rw-r--r-- | open_issues/dde.mdwn | 23 | ||||
-rw-r--r-- | open_issues/dde/137784 | 43 | ||||
-rw-r--r-- | open_issues/libpthread_pthread_key_create_reuse.mdwn | 82 | ||||
-rw-r--r-- | open_issues/libpthread_pthread_key_create_reuse/pthread_key_create_reuse.c | 48 | ||||
-rw-r--r-- | open_issues/performance/io_system/binutils_ld_64ksec.mdwn | 23 | ||||
-rw-r--r-- | open_issues/xen_lseek.mdwn | 22 | ||||
-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.mdwn | 30 | ||||
-rw-r--r-- | public_hurd_boxen/sceen.mdwn | 11 | ||||
-rw-r--r-- | user/Maksym_Planeta.mdwn | 135 | ||||
-rw-r--r-- | user/musial.mdwn | 19 |
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 |