summaryrefslogtreecommitdiff
path: root/hurd
diff options
context:
space:
mode:
Diffstat (limited to 'hurd')
-rw-r--r--hurd/debugging/rpctrace.mdwn80
-rw-r--r--hurd/libihash.mdwn8
-rw-r--r--hurd/running/debian/qemu_image.mdwn4
-rw-r--r--hurd/running/gnu/create_an_image.mdwn4
-rw-r--r--hurd/running/qemu.mdwn14
-rw-r--r--hurd/running/qemu/babhurd_image.mdwn3
-rw-r--r--hurd/running/qemu/discussion.mdwn96
-rw-r--r--hurd/running/qemu/microsoft_windows.mdwn13
-rw-r--r--hurd/running/qemu/writeback_caching.mdwn90
-rw-r--r--hurd/translator/ext2fs.mdwn44
-rw-r--r--hurd/translator/procfs.mdwn28
-rw-r--r--hurd/translator/procfs/jkoenig.mdwn23
-rw-r--r--hurd/translator/procfs/jkoenig/discussion.mdwn46
-rw-r--r--hurd/translator/short-circuiting.mdwn8
14 files changed, 306 insertions, 155 deletions
diff --git a/hurd/debugging/rpctrace.mdwn b/hurd/debugging/rpctrace.mdwn
index fd24f081..df6290f7 100644
--- a/hurd/debugging/rpctrace.mdwn
+++ b/hurd/debugging/rpctrace.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011 Free Software
+[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011, 2012 Free Software
Foundation, Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -89,6 +89,84 @@ See `rpctrace --help` about how to use it.
<pinotree> braunr: the output of rpctrace --help should tell the
default dir for msgids
+* IRC, freenode, #hurd, 2012-06-30
+
+ <mcsim> hello. Has anyone faced with problem when translator works
+ fine, but when it is started via rpctrace it hangs? Probably you know
+ what can cause this?
+ <antrik> mcsim: rpctrace itself is quite buggy
+ <antrik> zhengda once did a number of improvements, but they never went
+ upstream...
+ <youpi> well, he never explained how his fixes worked :)
+ <youpi> GNU/Hurd is no different from other projects in that regard: if
+ you don't explain how your patches work, there's low chance that they
+ are applied
+ <youpi> unless the maintainer has time to dive himself, which we don't
+ <pinotree> "it compiles, ship it!"
+ <braunr> pinotree: i guess the hurd is different in that particular
+ regard :p
+ <youpi> not different from linux
+ <braunr> eh, they include staging drivers now :)
+ <youpi> we have a sort-of staging tree as well, with netdde
+ <youpi> we don't really care about stability there
+ <antrik> youpi: actually, I think by now (and not to a small part
+ because of this episode) that we are too strict about patch
+ submission
+ <youpi> well, review really is needed, otherwise source gets into a bad
+ shape
+ <antrik> while zhengda's variant might not have been ideal (nobody of
+ us understands the workings of rpctrace enough to tell), I have
+ little doubt that it would be an improvement...
+ <youpi> it happened quite a few times that a fix revealed to be
+ actually bogus
+ <youpi> in that particular case, I agree
+ <youpi> the problem is that usually what happens is that questions are
+ asked
+ <youpi> and the answers never happen
+ <youpi> and thus the patch gets lost
+ <antrik> after all, when he when he submitted that patch, he had a much
+ better understanding of rpctrace than any of us...
+ <youpi> sure
+ <antrik> Linus is actually quite pragmatic about that. from what I've
+ seen, if he can be convinced that something is *probably* an
+ improvement over the previous status, he will usually merge it, even
+ if he has some qualms
+ <youpi> when there is a maintainer, he usually requires his approval,
+ doesn't he?
+ <antrik> in particular, for code that is new or has been in a very bad
+ shape before, standards shouldn't be as high as for changes to known
+ good code. and quite frankly, large parts of the Hurd code base
+ aren't all that good to begin with...
+ <youpi> sure
+ <antrik> well, sure. in this case, we should have just appointed
+ zhengda to be the rpctrace maintainer :-)
+ <antrik> BTW, as his version is quite fundamentally different, perhaps
+ instead of merging the very large patch, perhaps we should just ship
+ both versions, and perhaps drop the old one at some point if the new
+ one turns out to work well...
+ <antrik> (and perhaps I overused the word perhaps in that sentence
+ perhaps ;-) )
+ <youpi> about that particular patch, you had needed raised a few bits
+ <youpi> and there was no answers
+ <youpi> the patch is still in my mbox, far away
+ <youpi> so it was *not* technically lost
+ <youpi> it's just that as usual we lack manpower
+ <antrik> yeah, I know. but many of the things I raised were mostly
+ formalisms, which might be helpful for maintaining high-quality code,
+ but probably were just a waste of time and effort in this case... I'm
+ not surprised that zhengda lost motivation to pursue this further :-(
+ <braunr> it would help a lot to get the ton of patches in the debian
+ packages upstream :)
+ <youpi> braunr: there aren't many, and usually for a good reason
+ <youpi> some of them are in debian for testing, and can probably be
+ commited at some point
+ <pinotree> youpi: we could mark (with dep3 headers) the ones which are
+ meant to be debian-specific
+ <youpi> sure
+ <antrik> well, there are also a few patches that are not exactly
+ Debian-specific, but not ready for upstream either...
+ <youpi> antrik: yes
+
# See Also
diff --git a/hurd/libihash.mdwn b/hurd/libihash.mdwn
index 03ebae82..d6b8e8b6 100644
--- a/hurd/libihash.mdwn
+++ b/hurd/libihash.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2009, 2010, 2011 Free Software Foundation,
+[[!meta copyright="Copyright © 2009, 2010, 2011, 2012 Free Software Foundation,
Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -6,8 +6,8 @@ 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]]."]]"""]]
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
[[!tag open_issue_hurd]]
@@ -48,6 +48,8 @@ is included in the section entitled
* libstdc++: `unordered_map`, `tr1/unordered_map`, `ext/hash_map`
+ * libiberty: `hashtab.c`
+
* <http://cmph.sourceforge.net/>
* <http://libhashish.sourceforge.net/>
diff --git a/hurd/running/debian/qemu_image.mdwn b/hurd/running/debian/qemu_image.mdwn
index 19b371c1..de1027b7 100644
--- a/hurd/running/debian/qemu_image.mdwn
+++ b/hurd/running/debian/qemu_image.mdwn
@@ -15,7 +15,9 @@ Usage:
$ wget http://people.debian.org/~sthibault/hurd-i386/debian-hurd.img.tar.gz
$ tar -xz < debian-hurd.img.tar.gz
- $ qemu -m 512 -net nic,model=rtl8139 -net user -hda debian-hurd-*.img
+ $ qemu -m 512 -net nic,model=rtl8139 -net user -drive cache=writeback,index=0,media=disk,file=$(echo debian-hurd-*.img)
+
+See the discussion about [[hurd/running/qemu/writeback_caching]].
Just in case you were wondering: the *root* password is *root*.
diff --git a/hurd/running/gnu/create_an_image.mdwn b/hurd/running/gnu/create_an_image.mdwn
index 8784a826..98af99eb 100644
--- a/hurd/running/gnu/create_an_image.mdwn
+++ b/hurd/running/gnu/create_an_image.mdwn
@@ -18,7 +18,7 @@ Creating a bootable qemu image from a root filesystem and bootloader
2. Use a live CD (better to have a lighter OS like system rescue CD to make the
process faster) and the image created to boot.
- qemu -m 512 -cdrom /dev/cdrom -hda <imagename.img> -boot d
+ qemu -m 512 -cdrom /dev/cdrom -drive cache=writeback,index=0,media=disk,file=<imagename.img> -boot d
3. Once system is booted use a partition editing tool (like fdisk, cfdisk,
parted, gparted, qtparted ...) to partition the image.
@@ -65,7 +65,7 @@ Creating a bootable qemu image from a root filesystem and bootloader
11. Run qemu to boot into your brand new system
- qemu -m 512 -hda <hard disk image.img> -fda grub.img -boot a
+ qemu -m 512 -drive cache=writeback,index=0,media=disk,file=<hard disk image.img> -fda grub.img -boot a
Happy Hacking !!
diff --git a/hurd/running/qemu.mdwn b/hurd/running/qemu.mdwn
index b64c576f..512ea602 100644
--- a/hurd/running/qemu.mdwn
+++ b/hurd/running/qemu.mdwn
@@ -12,6 +12,8 @@ License|/fdl]]."]]"""]]
This page discusses things for [[Unix]] systems, there is a separate page for
[[Microsoft_Windows]] systems.
+See the discussion about [[hurd/running/qemu/writeback_caching]].
+
# Readily Available Images
You can use the following images to give the GNU/Hurd a try.
@@ -29,7 +31,7 @@ volunteers and may not have been tested extensively.
* [Disk image](http://draketo.de/dateien/hurd/bab-hurd-qemu-2008-10-29.img.tar.bz2)
with a short intro on translators. Just start it with `qemu -m 512
- disk_image.img`.
+ -drive cache=writeback,index=0,media=disk,file=disk_image.img`.
It should work without any of the configuration below. If you want to know what you can do
with it, please have a look at [[its_wikipage|hurd/running/qemu/babhurd_image]]. And when
you use it, please [tell me your experience with it](http://draketo.de/contact)! - [[community/weblogs/ArneBab]]
@@ -125,7 +127,7 @@ First off you will need to create a disk image using `qemu-img`. I have set mine
Next you will want to start up QEMU and begin the installation process.
- $ qemu -m 512 -hda hd0.img -cdrom mini.iso -net nic,model=rtl8139 -net user
+ $ qemu -m 512 -drive cache=writeback,index=0,media=disk,file=hd0.img -cdrom mini.iso -net nic,model=rtl8139 -net user
Now at his point do the regular install using `hd0` as your harddrive. Partition it and install the base system.
@@ -175,7 +177,7 @@ Also see another text about how to [[gnu/create_an_image]] for the
Starting qemu/qemu-kvm:
- $ kvm -m 512 -net nic,model=rtl8139 -net user,hostfwd=tcp::5555-:22 -hda hd0.img -vga vmware
+ $ kvm -m 512 -net nic,model=rtl8139 -net user,hostfwd=tcp::5555-:22 -drive cache=writeback,index=0,media=disk,file=hd0.img -vga vmware
vmsvga_value_write: guest runs Linux.
Note: See below on port forwarding in the networking section.
@@ -273,7 +275,7 @@ This is the recommended way to work with a Command Line Interface (CLI) since al
a) with ssh (assuming you have installed openssh-server)
- $ kvm -m 512 -net nic,model=rtl8139 -net user,hostfwd=tcp::5555-:22 -hda hd0.img &
+ $ kvm -m 512 -net nic,model=rtl8139 -net user,hostfwd=tcp::5555-:22 -drive cache=writeback,index=0,media=disk,file=hd0.img &
Logging in to the running Hurd:
@@ -290,7 +292,7 @@ Copying files:
b) with telnet (assuming you have installed a telnet server, like telnetd)
- $ kvm -m 512 -net nic,model=rtl8139 -net user,hostfwd=tcp::5556-:23 -hda hurd-install.qemu &
+ $ kvm -m 512 -net nic,model=rtl8139 -net user,hostfwd=tcp::5556-:23 -drive cache=writeback,index=0,media=disk,file=hurd-install.qemu &
Logging in to the running Hurd:
@@ -331,7 +333,7 @@ Now it is time to start-up your QEMU Hurd system and get networking going in the
**Important:** Remember you may need to use the `-M isapc` or `-isa` flag if using an older version of the gnumach package.
- $ qemu -m 512 -hda hd0.img -cdrom debian-K9-hurd-i386-CD1.iso -fda floppy.img -boot a -net nic -net tap
+ $ qemu -m 512 -drive cache=writeback,index=0,media=disk,file=hd0.img -cdrom debian-K9-hurd-i386-CD1.iso -fda floppy.img -boot a -net nic -net tap
Once you have logged in as `root` run the `pfinet` translator with values that apply to your network. Think of your QEMU client as another computer in your network.
diff --git a/hurd/running/qemu/babhurd_image.mdwn b/hurd/running/qemu/babhurd_image.mdwn
index 855e8f51..6a3bb30e 100644
--- a/hurd/running/qemu/babhurd_image.mdwn
+++ b/hurd/running/qemu/babhurd_image.mdwn
@@ -6,7 +6,8 @@ What this little Hurd image can do
This is the README file accompanying a
[disk\_image](http://draketo.de/dateien/hurd/bab-hurd-qemu-2008-10-29.img.tar.bz2) for
[[running the GNU/Hurd via qemu|hurd/running/qemu]]. To run the disk image,
-just use `qemu -m 512 disk_image.img`.
+just use `qemu -m 512 -drive
+cache=writeback,index=0,media=disk,file=disk_image.img`.
You can find the custom *.bashrc* used to tell the user about it as well as this text itself
in the Mercurial repository [hurd_intro](http://bitbucket.org/ArneBab/hurd_intro).
diff --git a/hurd/running/qemu/discussion.mdwn b/hurd/running/qemu/discussion.mdwn
index 1ce14b01..facb8a31 100644
--- a/hurd/running/qemu/discussion.mdwn
+++ b/hurd/running/qemu/discussion.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2009, 2010, 2011 Free
-Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012
+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
@@ -50,95 +50,3 @@ The problem is actually that the linux block cache doesn't make any consistency
between /dev/hda and /dev/hda6, so if you give /dev/hda to qemu, qemu writings
won't be consistent with mounting /dev/hda6 in linux. You can give /dev/hda6
directly to qemu and it will be fine.
-
-
-# Host-side Writeback Caching
-
-IRC, freenode, #hurd, 2011-06-07
-
- <braunr> hm, i guess i should have used cache=writeback with kvm before
- starting the debian installer :/
- <braunr> ah yes, much better
- <braunr> this shows how poor the state of our I/O drivers and subsystem is
- :/
- <antrik> indeed... still no clustered pageout :-(
- <braunr> and no I/O scheduler either
- <braunr> although an I/O scheduler has limited value without clustered
- pageouts
- <braunr> since one of its goals is to pack related I/O requests together eh
- <braunr> i wonder if the wiki mentions using cache=writeback to speed up
- qemu performances
- <braunr> it would help those unable to use kvm a lot
- <braunr> and even those running kvm too
- <braunr> kvm -m $RAM \ -monitor stdio \ -drive
- cache=writeback,index=0,media=disk,file=hd0.img \
- <braunr> etc..
- <braunr> the idea is that qemu doesn't open its disk file synchronously
- <braunr> changes are queued in the host page cache before being flushed to
- the disk image
- <braunr> but if you brutally close your qemu instance, you're likely to
- loose file system consistency
- <braunr> ext2fs will think it has committed its metadata to the disk, but
- the disk image won't be updated synchronously
- <braunr> on my machine (which is quite fast), my kvm has installed debian
- like 10 times faster than without the option
- <antrik> braunr: I don't think killing qemu should hurt in this
- case... probably only matters when the host machine dies
- <braunr> antrik: ah yes, right
- <braunr> it really makes everything faster, even downloading, since I/O
- requests aren't interleaved between networking RPCs
- <antrik> regarding I/O sheduler... this discussion came up before, but I
- don't remember the outcome -- doesn't the glued Linux driver actually
- come with one?
- <braunr> i don't remember either
- <antrik> braunr: err... I don't think interleaving has anything to do with
- it... I guess it's simply the fact that downloading writes the result to
- disk, which suffers from lacking clustered pageout like everything else
- <antrik> (my internet connection is too slow though to notice :-) )
- <braunr> well, if there is no I/O during downloading, downloading is faster
- :)
-
-IRC, freenode, #hurd, 2011-06-08
-
- <braunr> youpi: does xen provide disk caching options ?
- <youpi> through a blktap, probably
- <braunr> ok
-
-([[microkernel/mach/gnumach/ports/Xen]], *Host-side Writeback Caching*.)
-
- <braunr> we should find the pages mentioning qemu on the wiki and add the
- options to enable disk image caching
- <braunr> it really makes the hurd run a lot faster
- <braunr> as a workaround for emulators until I/O is reworked, ofc
-
-IRC, freenode, #hurd, 2011-06-09
-
- <gnu_srs> braunr recommends to use writeback caching with kvm. Is this
- really recommended with the frequent crashes I experience?
- <youpi> provided that you terminate your kvm normaly (i.e. quitting it, not
- killing it), there should be no difference
- <jkoenig> I think the host's stability is what matters
- <jkoenig> the data presumably sits in linux's cache even if qemu dies
- violently
- <gnu_srs> But the freezes I see force me to kill kvm :-(
- <youpi> maybe kvm doesn't even do caching indeed, I don't know
- <youpi> gnu_srs: you can quit even when frozen
- <youpi> use the console
- <youpi> (the kvm console)
- <jkoenig> gnu_srs, "Writeback caching will report data writes as completed
- as soon as the data is present in the host page cache. This is safe as
- long as you trust your host. If your host crashes or loses power, then
- the guest may experience data corruption." (from the qemu manpage)
-
-IRC, freenode, #hurd, 2011-06-11
-
- <gnu_srs> braunr: If you are online. For me setting the parameters -drive
- cache=writeback,index=0,media=disk,file=hd0.img does not show any speed
- improvement at all compared to the default.
- <braunr> gnu_srs: what's your complete qemu command line ?
- <gnu_srs> kvm -m 1024 -net nic,model=rtl8139 -net
- user,hostfwd=tcp::5556-:22 -drive
- cache=writeback,index=0,media=disk,file=hd0.img -cdrom netinst.iso
- <braunr> what qemu version ?
- <gnu_srs> qemu-kvm 0.14.1+dfsg-1: Sorry, I cannot be online until
- tomorrow again.
diff --git a/hurd/running/qemu/microsoft_windows.mdwn b/hurd/running/qemu/microsoft_windows.mdwn
index 832b4bef..e2c8636c 100644
--- a/hurd/running/qemu/microsoft_windows.mdwn
+++ b/hurd/running/qemu/microsoft_windows.mdwn
@@ -1,12 +1,13 @@
-[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2007, 2008, 2012 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]]."]]"""]]
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
Welcome, This document is for getting you started in a few minutes.
@@ -46,7 +47,5 @@ Welcome, This document is for getting you started in a few minutes.
## QEmu Image Hangs on Boot
The Debian GNU/Hurd K16 QEmu image hangs during the boot process. You may have better luck by converting the image to qcow format
- ..\qemu-0.9.0-x86\qemu-img.exe convert debian-hurd-k16-qemu.img -O
- qcow debian-hurd-k16-qemu.qcow
- ..\qemu-0.9.0-x86\qemu.exe -L ..\qemu-0.9.0-x86 -m 512 -hda
- debian-hurd-k16-qemu.qcow -localtime -M pc
+ ..\qemu-0.9.0-x86\qemu-img.exe convert debian-hurd-k16-qemu.img -O qcow debian-hurd-k16-qemu.qcow
+ ..\qemu-0.9.0-x86\qemu.exe -L ..\qemu-0.9.0-x86 -m 512 -drive cache=writeback,index=0,media=disk,file=debian-hurd-k16-qemu.qcow -localtime -M pc
diff --git a/hurd/running/qemu/writeback_caching.mdwn b/hurd/running/qemu/writeback_caching.mdwn
new file mode 100644
index 00000000..c9c53e3e
--- /dev/null
+++ b/hurd/running/qemu/writeback_caching.mdwn
@@ -0,0 +1,90 @@
+[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012
+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="Host-side Writeback Caching"]]
+
+[[!tag open_issue_documentation]]
+
+IRC, freenode, #hurd, 2011-06-07
+
+ <braunr> hm, i guess i should have used cache=writeback with kvm before
+ starting the debian installer :/
+ <braunr> ah yes, much better
+ <braunr> this shows how poor the state of our I/O drivers and subsystem is
+ :/
+ <antrik> indeed... still no clustered pageout :-(
+ <braunr> and no I/O scheduler either
+ <braunr> although an I/O scheduler has limited value without clustered
+ pageouts
+ <braunr> since one of its goals is to pack related I/O requests together eh
+ <braunr> i wonder if the wiki mentions using cache=writeback to speed up
+ qemu performances
+ <braunr> it would help those unable to use kvm a lot
+ <braunr> and even those running kvm too
+ <braunr> kvm -m $RAM \ -monitor stdio \ -drive
+ cache=writeback,index=0,media=disk,file=hd0.img \
+ <braunr> etc..
+ <braunr> the idea is that qemu doesn't open its disk file synchronously
+ <braunr> changes are queued in the host page cache before being flushed to
+ the disk image
+ <braunr> but if you brutally close your qemu instance, you're likely to
+ loose file system consistency
+ <braunr> ext2fs will think it has committed its metadata to the disk, but
+ the disk image won't be updated synchronously
+ <braunr> on my machine (which is quite fast), my kvm has installed debian
+ like 10 times faster than without the option
+ <antrik> braunr: I don't think killing qemu should hurt in this
+ case... probably only matters when the host machine dies
+ <braunr> antrik: ah yes, right
+ <braunr> it really makes everything faster, even downloading, since I/O
+ requests aren't interleaved between networking RPCs
+ <antrik> regarding I/O sheduler... this discussion came up before, but I
+ don't remember the outcome -- doesn't the glued Linux driver actually
+ come with one?
+ <braunr> i don't remember either
+ <antrik> braunr: err... I don't think interleaving has anything to do with
+ it... I guess it's simply the fact that downloading writes the result to
+ disk, which suffers from lacking clustered pageout like everything else
+ <antrik> (my internet connection is too slow though to notice :-) )
+ <braunr> well, if there is no I/O during downloading, downloading is faster
+ :)
+
+IRC, freenode, #hurd, 2011-06-08
+
+ <braunr> youpi: does xen provide disk caching options ?
+ <youpi> through a blktap, probably
+ <braunr> ok
+
+([[microkernel/mach/gnumach/ports/Xen]], *Host-side Writeback Caching*.)
+
+ <braunr> we should find the pages mentioning qemu on the wiki and add the
+ options to enable disk image caching
+ <braunr> it really makes the hurd run a lot faster
+ <braunr> as a workaround for emulators until I/O is reworked, ofc
+
+IRC, freenode, #hurd, 2011-06-09
+
+ <gnu_srs> braunr recommends to use writeback caching with kvm. Is this
+ really recommended with the frequent crashes I experience?
+ <youpi> provided that you terminate your kvm normaly (i.e. quitting it, not
+ killing it), there should be no difference
+ <jkoenig> I think the host's stability is what matters
+ <jkoenig> the data presumably sits in linux's cache even if qemu dies
+ violently
+ <gnu_srs> But the freezes I see force me to kill kvm :-(
+ <youpi> maybe kvm doesn't even do caching indeed, I don't know
+ <youpi> gnu_srs: you can quit even when frozen
+ <youpi> use the console
+ <youpi> (the kvm console)
+ <jkoenig> gnu_srs, "Writeback caching will report data writes as completed
+ as soon as the data is present in the host page cache. This is safe as
+ long as you trust your host. If your host crashes or loses power, then
+ the guest may experience data corruption." (from the qemu manpage)
diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn
index ad79c7b9..8e15d1c7 100644
--- a/hurd/translator/ext2fs.mdwn
+++ b/hurd/translator/ext2fs.mdwn
@@ -18,6 +18,8 @@ License|/fdl]]."]]"""]]
* [[Page_cache]]
+ * [[metadata_caching]]
+
## Large Stores
@@ -43,6 +45,48 @@ Smaller block sizes are commonly automatically selected by `mke2fs` when using
small backend stores, like floppy devices.
+#### IRC, freenode, #hurd, 2012-06-30
+
+ <braunr> at least having the same api in the debian package and the git
+ source would be great (in reference to the large store patch ofc)
+ <youpi> braunr: the api part could be merged perhaps
+ <youpi> it's very small apparently
+ <antrik> braunr: the large store patch is a sad story. when it was first
+ submitted, one of the maintainers raised some concerns. the other didn't
+ share these (don't remember who is who), but the concerned one never
+ followed up with details. so it has been in limbo ever since. tschwinge
+ once promised to take it up, but didn't get around to it so far. plus,
+ the original author himself mentioned once that he didn't consider it
+ finished...
+ <youpi> antrik: it's clearly not finished
+ <youpi> there are XXXs here and there
+ <braunr> it's called an RC1 and RC2 is mentioned in the release notes
+ <antrik> youpi: well, that doesn't stop most other projects from commiting
+ stuff... including most emphatically the original Hurd code :-)
+ <youpi> what do you refer to my "that" ? :)
+ <braunr> "XXX"
+ <youpi> right
+ <youpi> at the time it made sense to delay applying
+ <youpi> but I guess by nowadays standard we should just as well commit it
+ <youpi> it works enough for Debian, already
+ <youpi> there is just one bug I nkow about
+ <youpi> the apt database file keeps haveing the wrong size, fixed by e2fsck
+ <pinotree> youpi: remember that patch should be fixed in the offset
+ declaration in diskfs.h
+ <youpi> I don't remember about that
+ <youpi> did we fix it in the debian package?
+ <pinotree> nope
+ <youpi> you had issues when fixing it, didn't you?
+ <youpi> (I don't remember where I can find the details about this)
+ <pinotree> i changed it, recompiled hurd and installed it, started a perl
+ rebuild and when running one of the two lfs tests it hard locked the vm
+ after ext2fs was taking 100% cpu for a bit
+ <pinotree> i don't exclude i could have done something stupid on my side
+ though
+ <youpi> or there could just be actual issues, uncovered here
+ <youpi> which can be quite probable
+
+
# Documentation
* <http://e2fsprogs.sourceforge.net/ext2.html>
diff --git a/hurd/translator/procfs.mdwn b/hurd/translator/procfs.mdwn
index 70448e94..cccce0b7 100644
--- a/hurd/translator/procfs.mdwn
+++ b/hurd/translator/procfs.mdwn
@@ -1,13 +1,13 @@
-[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation,
-Inc."]]
+[[!meta copyright="Copyright © 2008, 2009, 2010, 2011, 2012 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]]."]]"""]]
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
Although there is no standard (POSIX or other) for the layout of the `/proc`
pseudo-filesystem, it turned out a very useful facility in GNU/Linux and other
@@ -23,13 +23,23 @@ management tools to work. (On Linux, the `/proc` filesystem is used also for
debugging purposes; but this is highly system-specific anyways, so there is
probably no point in trying to duplicate this functionality as well...)
-*Status*: Madhusudan.C.S has implemented a new, fully functional [[procfs|madhusudancs]] for
-[[GSoC 2008|community/gsoc/2008]].
+Ther was an implementation in [[open_issues/HurdExtras]],
+<http://www.nongnu.org/hurdextras/#procfs>.
+Madhusudan.C.S has implemented a new, fully functional [[procfs|madhusudancs]] for
+[[GSoC 2008|community/gsoc/2008]].
-# [[New Implementation by Jérémie Koenig|jkoenig]]
+In August 2010, Jérémie Koenig [published another, new
+version](http://lists.gnu.org/archive/html/bug-hurd/2010-08/msg00165.html).
+This can be found in <http://git.savannah.gnu.org/cgit/hurd/procfs.git/>.
+Testing it is as simple as this:
-# Old Implementation from [[open_issues/HurdExtras]]
+ $ git clone git://git.savannah.gnu.org/hurd/procfs.git
+ $ cd procfs/
+ $ git checkout master
+ $ make
+ $ settrans -ca proc procfs --compatible
+ $ ls -l proc/
-<http://www.nongnu.org/hurdextras/#procfs>
+[[Open issues|jkoenig/discussion]].
diff --git a/hurd/translator/procfs/jkoenig.mdwn b/hurd/translator/procfs/jkoenig.mdwn
deleted file mode 100644
index 9543b658..00000000
--- a/hurd/translator/procfs/jkoenig.mdwn
+++ /dev/null
@@ -1,23 +0,0 @@
-[[!meta copyright="Copyright © 2010, 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]]."]]"""]]
-
-In August 2010, Jérémie Koenig [published another, new
-version](http://lists.gnu.org/archive/html/bug-hurd/2010-08/msg00165.html).
-This can be found in <http://git.savannah.gnu.org/cgit/hurd/procfs.git/>,
-branch *jkoenig/master*.
-
-Testing it is as simple as this:
-
- $ git clone git://git.savannah.gnu.org/hurd/procfs.git
- $ cd procfs/
- $ git checkout jkoenig/master
- $ make
- $ settrans -ca proc procfs --compatible
- $ ls -l proc/
diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn
index e7fdf46e..4f6492ed 100644
--- a/hurd/translator/procfs/jkoenig/discussion.mdwn
+++ b/hurd/translator/procfs/jkoenig/discussion.mdwn
@@ -18,9 +18,6 @@ License|/fdl]]."]]"""]]
IRC, #hurd, around September 2010
- <youpi> jkoenig: from a quick read, your procfs implementation seems quite
- simple, probably much more what I was expecting from Madhusudan (who
- probably now hates you :) )
<youpi> jkoenig: is it not possible to provide a /proc/self which points at
the client's pid?
<pinotree> (also, shouldn't /proc/version say something else than "Linux"?)
@@ -68,7 +65,7 @@ IRC, #hurd, around October 2010
owner, but always with root group
-# `/proc/$pid/stat` being 400 and not 444, and some more
+# `/proc/[PID]/stat` being 400 and not 444, and some more
IRC, freenode, #hurd, 2011-03-27
@@ -187,7 +184,7 @@ IRC, freenode, #hurd, 2011-07-22
server anyway, I think.
-# `/proc/mounts`, `/proc/$pid/mounts`
+# `/proc/mounts`, `/proc/[PID]/mounts`
IRC, freenode, #hurd, 2011-07-25
@@ -277,3 +274,42 @@ Needed by glibc's `pldd` tool (commit
<antrik> it's very weird for example for fd connected to files that have
been unlinked. it looks like a broken symlink, but when dereferencing
(e.g. with cp), you get the actual file contents...
+
+
+# `/proc/[PID]/maps`
+
+## IRC, OFTC, #debian-hurd, 2012-06-20
+
+ <pinotree> bdefreese: the two elfutils tests fail because there are no
+ /proc/$pid/maps files
+ <pinotree> that code is quite relying on linux features, like locating the
+ linux kernel executables and their modules, etc
+ <pinotree> (see eg libdwfl/linux-kernel-modules.c)
+ <pinotree> refactor elfutils to have the linux parts executed only on linux
+ :D
+ <bdefreese> Oh yeah, the maintainer already seems really thrilled about
+ Hurd.. Did you see
+ http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662041 ?
+ <pinotree> kurt is generally helpful with us (= hurd)
+ <pinotree> most probably there he is complaining that we let elfutils build
+ with nocheck (ie skipping the test suite run) instead of investigate and
+ report why the test suite failed
+
+
+# IRC, freenode, #hurd, 2011-06-19
+
+ <pinotree> jkoenig: procfs question: in process.c, process_lookup_pid, why
+ is the entries[2].hook line repeated twice?
+ <jkoenig> pinotree, let me check
+ <jkoenig> pinotree, it's probably just a mistake, there's no way the second
+ one has any effect
+ <pinotree> jkoenig: i see, it looked like you c&p'd that code accidentally
+ <jkoenig> pinotree, it's probably what happened, yes.
+
+
+# `/proc/[PID]/cwd`
+
+## IRC, freenode, #hurd, 2012-06-30
+
+ * pinotree has a local work to add the /proc/$pid/cwd symlink, but relying
+ on "internal" (but exported) glibc functions
diff --git a/hurd/translator/short-circuiting.mdwn b/hurd/translator/short-circuiting.mdwn
index 9de9f7b8..6f608fb2 100644
--- a/hurd/translator/short-circuiting.mdwn
+++ b/hurd/translator/short-circuiting.mdwn
@@ -1,12 +1,12 @@
-[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2009, 2012 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]]."]]"""]]
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
In traditional [[Unix]], file systems contain special files. These are:
symbolic links, character devices, block devices, named pipes, and
@@ -60,6 +60,8 @@ To make sure that you use one of these translators, there by bypassing the
short-circuiting mechanism, you can either start it as
an active translator, or use a different path from the one in
`hurd/path.h`, e.g. `settrans bar /hurd/./symlink foo`.
+There is also a `FS_TRANS_FORCE` flag defined for the `file_set_translator`
+RPCs, but it currently isn't set from anywhere.
The best example of how short-circuiting is implemented can be found
in [[`libdiskfs`|libdiskfs]]. Notice how it detects if a translator to store
generated by cgit v1.2.3 (git 2.46.0) at 2025-03-03 20:20:17 +0000