Merge branch 'master' of braunbox:~hurd-web/hurd-web

6 files changed, 284 insertions, 14 deletions

diff --git a/faq/how_many_developers.mdwn b/faq/how_many_developers.mdwn
index 2a3894bd..da457d96 100644
--- a/faq/how_many_developers.mdwn
+++ b/faq/how_many_developers.mdwn
@@ -34,6 +34,9 @@ development.  For one, this is a good thing: independency; no conflicts of
 interests.  For another, it is also a bad thing: no dedicated full-time
 manpower -- which matters a lot.
 
+This also answers the question why [[the Hurd still does not do [...] after so
+many years of development|so_many_years]].
+
 
 # Why So Few?
 
diff --git a/faq/libpthread_plugin.mdwn b/faq/libpthread_dlopen.mdwn
index bcbe9571..5fb77767 100644
--- a/faq/libpthread_plugin.mdwn
+++ b/faq/libpthread_dlopen.mdwn
@@ -10,12 +10,16 @@ License|/fdl]]."]]"""]]
 
 [[!tag faq/open_issues]]
 
-[[!meta title="Getting Assertion `__pthread_threads' failed."]]
+[[!meta title="Assertion `__pthread_threads' failed"]]
 
-Some applications don't link against libpthread, but load plugins which do link against libpthread. This means unexpectedly switch from mono-thread to multi-thread. This is not supported yet, thus the following error:
+Some applications don't themselves link against libpthread, but then load
+plugins which do link against libpthread.  This means internally switching from
+single-threading to multi-threading, which is [[not yet
+supported|open_issues/libpthread_dlopen]] by our [[/libpthread]], and results
+in errors such as:
 
     ./pthread/../sysdeps/generic/pt-mutex-timedlock.c:70: __pthread_mutex_timedlock_internal: Assertion `__pthread_threads' failed.
 
-This can be worked around by using
+This can be worked around by explicitly pre-loading libpthread, for example:
 
-export LD_PRELOAD=/lib/i386-gnu/libpthread.so.0.3
+    $ LD_PRELOAD=/lib/i386-gnu/libpthread.so.0.3 [application]
diff --git a/faq/sata_disk_drives/discussion.mdwn b/faq/sata_disk_drives/discussion.mdwn
new file mode 100644
index 00000000..e9da8560
--- /dev/null
+++ b/faq/sata_disk_drives/discussion.mdwn
@@ -0,0 +1,240 @@
+[[!meta copyright="Copyright © 2013 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!tag open_issue_gnumach]]
+
+
+# IRC, freenode, #hurd, 2013-05-10
+
+    <braunr> what code have you used if any (or is it your own implementation)
+      ?
+    <youpi> I ended up writing my own implementation
+    <braunr> eh :)
+    <youpi> the libahci/ahci code from linux is full of linux-specific stuff
+    <youpi> it would mean working on gluing that
+    <youpi> which woudl rather be just done in block-dde
+    <youpi> I was told at fosdem that ahci is not actually very difficult
+    <youpi> and it isn't indeed
+    <braunr> that's why i usually encourage to use netbsd code
+
+    <braunr> any chance using ahci might speed up our virtual machines ?
+    <youpi> they are already using DMA, so probably no
+    <youpi> (with the driver I've pushed)
+    <youpi> adding support for tagged requests would permit to submit several
+      requests at a time
+    <youpi> _that_ could improve it
+    <youpi> (it would make it quite more complex too)
+    <youpi> but not so much actually
+
+    <anatoly> What about virtio? will it speed up?
+
+[[open_issues/virtio]].
+
+    <youpi> probably not so much
+    <youpi> because in the end it works the same
+    <youpi> the guest writes the physical addresse in mapped memory
+    <youpi> kvm performs the read into th epointed memory, triggers an irq
+    <youpi> the guest takes the irq, marks as done, starts the next request,
+      etc.
+    <youpi> most enhancements that virtio could bring can already be achieved
+      with ahci
+    <youpi> one can probably go further with virtio, but doing it with ahci
+      will also benefit bare hardware
+
+    <pinotree> http://en.wikipedia.org/wiki/AHCI
+    <youpi> anatoly: aka SATA
+    <anatoly> some sort of general protocol to work with any SATA drive via
+      AHCI-compatible host controller?
+    <braunr> yes
+
+    <youpi> braunr: I may be mistaken, but it does seem ahci is faster than ide
+    <youpi> possibly because the ide driver is full of hardcoded wait loops
+    <braunr> interesting :)
+    <youpi> usleeps here and there
+    <braunr> oh right
+    <braunr> i wonder how they're actually implemented
+    <youpi> so it would make sense to use that on shattrath
+    <youpi> a nasty buggy busy-loop
+    <braunr> yes but ending when ?
+    <youpi> when a given number of loops have elapsed
+    <youpi> that's where "buggy" applies :)
+    <braunr> ok so buggy implies the loop isn't correctly calibrated
+    <youpi> it isn't calibrated at all actually
+    <braunr> ew
+    <youpi> it was probably calibrated on some 486 or pentium hardware :)
+    <braunr> yeah that's what i imagined too
+    <braunr> we'll need some measurements but if it's actually true, it's even
+      better news
+
+
+## IRC, freenode, #hurd, 2013-05-11
+
+    <youpi> ah, also, worth mentioning: the AHCI driver supports up to 2TiB
+      disks
+    <youpi> (as opposed to our IDE driver which supports only LBA28, 128GiB)
+    <youpi> supporting more than 2TiB would require an RPC change, or using
+      bigger sectors
+    <youpi> (which wouldn't be a bad idea anyway)
+    <braunr> i think we should switch to uint64_t addressable vm_objects
+    <braunr> which would allow to support large files too
+    <youpi> braunr: yep
+
+
+## IRC, freenode, #hurd, 2013-05-13
+
+    <braunr> the hurd, running on vbox, with a sata controler :)
+    <braunr> hum, problem with an extended partition
+    <anatoly_> qemu/kbm doesn't have sata controller, am I right?
+    <braunr> anatoly: recent versions might
+    <braunr> http://wiki.qemu.org/Features/AHCI
+    <braunr> www.linux-kvm.org/wiki/images/7/73/2011-forum-ahci.pdf
+    <anatoly> braunr: found first link, too. Thanx for the second one
+    <braunr>
+      http://git.qemu.org/?p=qemu.git;a=blob;f=hw/ide/ahci.c;h=eab60961bd818c22cf819d85d0bd5485d3a17754;hb=HEAD
+    <braunr> looks ok in recent versions
+    <braunr> looks useful to have virtio drivers though
+
+[[open_issues/virtio]].
+
+    <anatoly> virtio is shown as fastest way for IO in the presentation
+    <anatoly> Hm, failed to run qemu with AHCI enabled
+    <anatoly> qemu 1.1 from debian testing
+    <anatoly> youpi how do run qemu with AHCI enabled?
+
+
+## IRC, freenode, #hurd, 2013-05-14
+
+    <anatoly> can somebody ask youpi how he runs qemu with AHCI please?
+    <gnu_srs> I think he used vbox?  Did not find any AHCI option for kvm
+      (1.1.2-+dfsg-6)
+    <anatoly> gnu_srs: http://wiki.qemu.org/ChangeLog/0.14#IDE_.2F_AHCI
+    <anatoly> but it doesn't work for me the same version of kvm
+    <braunr_> anatoly: have you checked how the debian package builds it ?
+    <anatoly> braunr: mach sees AHCI device
+    <braunr> oh :)
+    <anatoly> the problem is in last option "-device
+      ide-drive,drive=disk,bus=ahci.0"
+    <anatoly> lvm says 'invalid option'
+    <braunr> anatoly: can you give more details please ?
+    <braunr> lvm ?
+    <anatoly> s/lvm/kvm
+    <braunr> i don't understand
+    <braunr> how can mach probe an ahci drive if you can't start kvm ?
+    <anatoly> I ran it without last option
+    <braunr> then why do you want that option ?
+    <anatoly> But, actually I entered command with mistake. I retried it and it
+      works. But got "start ext2fs: ext2fs: device:hd0s2: No such device or
+      address"
+    <anatoly> Sorry for confusing
+    <braunr> that's normal
+    <braunr> it should be sd0s2
+    <bddebian2> Right because the device names are different
+    <braunr> be aware that gnumach couln't see my extended partitions when i
+      tried that yesterday
+    <braunr> i don't know what causes the problem
+    <anatoly> Yeah, I understand, I just note about it to show that it works
+    <braunr> :)
+    <anatoly> And I was wring
+    <anatoly> s/wring/wrong
+    <braunr> is that the version in wheezy ?
+    <anatoly> I'm using testing, but it's same
+    <braunr> great
+    <braunr> the sceen.net VMs will soon use that then
+    <anatoly> I don't have extended partions
+    <anatoly> Booted with AHCI! :-)
+    <anatoly> It freezes while downloading packages for build-essential
+      fake-root dependencies with AHCI enabled
+    <youpi> anatoly: is the IRQ of the ahci controller the same as for your
+      ethernet device? (you can see that in lspci -v)
+    <anatoly> youpi: will check
+    <anatoly> youpi both uses IRQ 111
+    <anatoly> s/111/11
+    <braunr> aw
+    <youpi> anatoly: ok, that might be why
+    <youpi> is this kvm?
+    <youpi> if so, you can set up a second ahci controler
+    <youpi> and attach devices to it
+    <youpi> so the irq is not the same
+    <youpi> basically, the issue is about dde disabling the irq
+    <youpi> during interrupt handler
+    <youpi> which conflicts with ahci driver needs
+
+
+## IRC, freenode, #hurd, 2013-05-15
+
+    <anatoly> youpi: yes, it's kvm. Will try a second ahci controller
+
+    <Slex> I read recentrly was added ahci driver, is it in userland or
+      kernel-land?
+    <gnu_srs> kernel-land the change was in gnumach
+
+
+## IRC, freenode, #hurd, 2013-05-18
+
+    <youpi> about the IRQ conflict, it's simply that both dde and the ahci
+      driver need to disable it
+    <youpi> it needs to be coherent somehow
+
+
+## IRC, freenode, #hurd, 2013-05-20
+
+    <anatoly> gnu_srs: kvm -m 1G -drive
+      id=disk,file=<path_hurd_disk_img>,if=none,cache=writeback -device
+      ahci,id=ahci-1 -device ahci,id=ahci-2 -device
+      ide-drive,drive=disk,bus=ahci-2.0
+    <anatoly> who knows what does "ich9-ahci.multifunction=on/off" parameter
+      for kvm's ahci device mean?
+    <anatoly> well, I was a bit incorrect :-) The options is relative to PCI
+      miltifunction devices
+    <anatoly> s/options is relative/options relates
+
+
+## IRC, freenode, #hurd, 2013-05-24
+
+    <anatoly> I don't see freezes anymore while downloading packages with AHCI
+      enabled
+    <youpi> anatoly: by fixing the shared IRQ ?
+    <anatoly> youpi: yes, I added second AHCI as you suggested
+    <youpi> ok
+    <youpi> so it's probably the shared IRQ issue
+    <anatoly> NIC and AHCI have similar IRQ when only one AHCI is enabled
+    <anatoly> according lspci output
+    <youpi> yes
+
+
+## IRC, freenode, #hurd, 2013-06-18
+
+    <braunr> youpi: is there a simple way from hurd to check interrupts ?
+    <youpi> what do you mean by "check interrupts" ?
+    <braunr> if they're shared
+    <youpi> I still don't understand :)
+    <braunr> i'm setting up sata
+    <youpi> ah, knowing the number
+    <braunr> yes
+    <youpi> you can read that from lspci -v
+    <braunr> ok
+    <braunr> thanks
+    <braunr> hum
+    <braunr> i get set root='hd-49,msdos1' in grub.cfg when changing the
+      device.map file to point to sd0
+    <youpi> hum
+    <braunr> i wonder if it's necessary
+    <braunr> i guess i just have to tell gnumach to look for sd0, not grub
+    <braunr> youpi: the trick you mentioned was to add another controler, right
+      ?
+    <youpi> yes
+    <braunr> ok
+    <braunr> youpi: looks fine :)
+    <braunr> and yes, i left hd0 in grub's device.map
+    <braunr> although i have lots of errors on hd0s6 (/home)
+    <braunr> youpi: there must be a bug with large sizes
+    <braunr> i'll stick with ide for now, but at least setting sata with
+      libvirt was quite easy to do
+    <braunr> so we can easily switch later
diff --git a/faq/so_many_years.mdwn b/faq/so_many_years.mdwn
index 8c5ce4a0..f69243f5 100644
--- a/faq/so_many_years.mdwn
+++ b/faq/so_many_years.mdwn
@@ -1,5 +1,4 @@
-[[!meta copyright="Copyright © 2013 Free Software Foundation,
-Inc."]]
+[[!meta copyright="Copyright © 2013 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
@@ -11,11 +10,11 @@ License|/fdl]]."]]"""]]
 
 [[!tag faq/general faq/_important]]
 
-[[!meta title="How is it that the Hurd does not do foo and bar, after so many years of development?"]]
+[[!meta title="Why is it that the Hurd still does not do [...] after so many
+years of development?"]]
 
-
-Remember that what counts is years.people, not just years, so it
-can't be compared to e.g. Linux or BSD development so trivially. See
-[[how_many_developers|how many developers]] are working on the Hurd, it is
-actually impressive that so much has been done in the past couple of decades
-with so few people.
+Remember that what counts is not just *years* but rather *years x people*, and
+in this regard, the investment into GNU Hurd's development is way below that of
+the Linux kernel or the BSDs.  Considering [[how_many_developers]] are (and
+have been) working on the Hurd, it is actually impressive that so much has been
+achieved in the past couple of decades with so few people.
diff --git a/faq/still_useful.mdwn b/faq/still_useful.mdwn
index 8d7e3f28..d08d2df7 100644
--- a/faq/still_useful.mdwn
+++ b/faq/still_useful.mdwn
@@ -68,6 +68,6 @@ various servers are designed for this sort of modification.
 > drivers are actually Linux drivers running in a separate userland process.
 
 > It also for instance provides very fine-grain virtualization support, such as
-> VPN for only one process, etc.
+> [[VPN for only one process|open_issues/virtualization/networking]], etc.
 
 > etc. etc. The implications are really very diverse...
diff --git a/faq/system_port.mdwn b/faq/system_port.mdwn
index fc710a3e..ca96697c 100644
--- a/faq/system_port.mdwn
+++ b/faq/system_port.mdwn
@@ -47,3 +47,27 @@ Mach run as a POSIX user-space process|open_issues/mach_on_top_of_posix]], or
 by implementing the [[Mach IPC|microkernel/mach/ipc]] facility (as well as
 several others) as Linux kernel modules.  While there have been some
 experiments, no such port has been completed yet.
+
+
+# IRC, freenode, #hurd, 2013-09-05
+
+    <rah> what would be required to port the hurd to sparc?
+    <pinotree> port gnumach, write the sparc bits of mach/hurd in glibc, and
+      maybe some small parts in hurd itself too
+    <rah> what would be required to port gnumach? :-)
+    <braunr> a new arch/ directory
+    <braunr> bootstrap code
+    <braunr> pmap (mmu handling) code
+    <braunr> trap handling
+    <braunr> basic device support (timers for example)
+    <braunr> besides, sparc is a weird beast
+    <braunr> so expect to need to work around tricky issues
+    <braunr> in addition, sparc is dead
+    <rah> mmm
+    <rah> it's not totally dead
+    <rah> the T1 chips and their decendents are still in production
+    <rah> the thing is I'd like to have real hardware for the hurd
+    <rah> and if I'm going to have two machines running at once, I'd rather one
+      of them was my UltraSPARC box :-)
+    <braunr> rah: unless you work hard on it, it's unlikely you'll get it
+    <rah> braunr: of course