diff options
Diffstat (limited to 'faq')
| -rw-r--r-- | faq/how_many_developers.mdwn | 3 | ||||
| -rw-r--r-- | faq/libpthread_dlopen.mdwn (renamed from faq/libpthread_plugin.mdwn) | 12 | ||||
| -rw-r--r-- | faq/sata_disk_drives/discussion.mdwn | 240 | ||||
| -rw-r--r-- | faq/so_many_years.mdwn | 17 | ||||
| -rw-r--r-- | faq/still_useful.mdwn | 2 | ||||
| -rw-r--r-- | faq/system_port.mdwn | 24 |
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 |