diff options
Diffstat (limited to 'open_issues')
48 files changed, 2145 insertions, 3271 deletions
diff --git a/open_issues/64-bit_port.mdwn b/open_issues/64-bit_port.mdwn index 9382a0d5..77b0632e 100644 --- a/open_issues/64-bit_port.mdwn +++ b/open_issues/64-bit_port.mdwn @@ -13,79 +13,163 @@ License|/fdl]]."]]"""]] [[!inline pages="title(Is there a 64-bit version?)" feeds="no" raw="yes"]] -There is a `master-x86_64` [[GNU Mach -branch|http://git.savannah.gnu.org/cgit/hurd/gnumach.git/log/?h=master-x86_64]]. -As of 2012-11-20, it only supports the [[microkernel/mach/gnumach/ports/Xen]] platform for now. - **What is left for initial support (32-on-64) is** - * add 64bit boot support from grub's multiboot - * implement 32/64 RPC compatibility for RPCs served by kernel. - -See [[http://lists.gnu.org/archive/html/bug-hurd/2012-04/msg00000.html]] + * Fixing bugs :) **For pure 64bit support, we need to** - * add 64bit definitions in binutils - * add 64bit definitions in gcc - * implement 64bit variants of code in glibc/sysdeps/mach/i386 and glibc/sysdeps/mach/hurd/i386 - * implement 64bit variants of code in libpthread/sysdeps/i386, libpthread/sysdeps/mach/i386, libpthread/sysdeps/mach/hurd/i386 - * fetch from Linux 64bit variant of code in ./pfinet/linux-src/arch/i386 and ./pfinet/linux-src/include/asm-i386 - * define the mig ABI - * bootstrap a distrib, e.g. Debian hurd-amd64 (see [[https://jenkins.debian.net/view/rebootstrap/job/rebootstrap_hurd-amd64_gcc8/]] ) - -# IRC, freenode, #hurd, 2011-10-16 - - <youpi> it'd be really good to have a 64bit kernel, no need to care about - addressing space :) - <braunr> yes a 64 bits kernel would be nice - <braunr> i guess it wouldn't be too hard to have a special mach kernel for - 64 bits processors, but 32 bits userland only - <youpi> well, it means tinkering with mig - -[[mig_portable_rpc_declarations]]. - - -# IRC, freenode, #hurd, 2012-10-03 - - <braunr> youpi: just so you know in case you try the master-x86_64 with - grub - <braunr> youpi: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689509 - <youpi> ok, thx - <braunr> the squeeze version is fine but i had to patch the wheezy/sid one - <youpi> I actually hadn't hoped to boot into 64bit directly from grub - <braunr> youpi: there is code in viengoos that could be reused - <braunr> i've been thinking about it for a time now - <youpi> ok - <braunr> the two easiest ways are 1/ the viengoos one (a -m32 object file - converted with objcopy as an embedded loader) - <braunr> and 2/ establishing an identity mapping using 4x1 GB large pages - and switching to long mode, then jumping to c code to complete the - initialization - <braunr> i think i'll go the second way with x15, so you'll have the two :) - - -## IRC, freenode, #hurd, 2013-07-02 - -In context of [[mondriaan_memory_protection]]. - - <xscript> BTW, it's not like I have an infinite amount of time for this, - but having 64-bit support would be valuable for me, so I might contribute - that back if it's not a too monumental task - <xscript> I saw some discussions about 32bit apps on top of 64bit mach, but - I'd like a full 64bit system - <xscript> any clues? - <xscript> I suppose the compiler support is all there already - <xscript> is MIG (and mach) the only piece missing? - <braunr> the problem is the interfaces themselves - <braunr> type widths - <braunr> as passed between userspace and kernel - - -## IRC, OFTC, #debian-hurd, 2013-10-05 - - <dharc> and what about 64 bit support, almost done? - <youpi> kernel part is done - <youpi> MIG 32/64 trnaslation missing - -[[mig_portable_rpc_declarations]]. + * bootstrap a distrib + * port gdb + * Fix bugs :) + * Notably it seems to be requiring at least 2G memory to boot. + +**Installing a 64bit chroot** + +You can use the pre-built image from https://people.debian.org/~sthibault/hurd-i386/initrd-amd64.img.gz and boot that. + +Make sure to have `debootstrap >= 1.0.128+nmu2+hurd.1` + + debootstrap --foreign --verbose --arch hurd-amd64 --include=debian-keyring,wget,curl,inetutils-ping,openssh-server,openssh-client,nano,less --keyring=/usr/share/keyrings/debian-keyring.gpg sid chroot-hurd-amd64 https://people.debian.org/~sthibault/tmp/hurd-amd64 + mkdir chroot-hurd-amd64/etc/apt/trusted.gpg.d + ln -s /usr/share/keyrings/debian-keyring.gpg chroot-hurd-amd64/etc/apt/trusted.gpg.d/ + +Then boot it, it will drop you into a shell. You'll probably want to use a nicer shell: + + bash + +You need to make / writable: + + fsysopts / --writable + +and then run the second stage of the deboostrap (and clear debs): + + /debootstrap/debootstrap --second-stage + apt clean + +set a root password: + + passwd + +Avoid core dumpings for now (not supported and hangs): + + rm -f /servers/crash + ln -s crash-kill /servers/crash + +Disable the Hurd console, buggy for now: + + export TERM=mach + nano /etc/default/hurd + # set ENABLE to 'false' + +And reboot: + + reboot-hurd + +After reboot, you'll probably want to setup network: + + vi /etc/network/interfaces + # put there this: + auto /dev/eth0 + iface /dev/eth0 inet static + address 10.0.2.15/16 + gateway 10.0.2.2 + +**Creating a 64bit disk image** + +You can use the pre-built image from https://people.debian.org/~sthibault/hurd-i386/disk-amd64.img.gz and boot that. + +To make a bootable system we really better make the disk image partitioned, and mount the partition: + + dd < /dev/zero > disk.img bs=1M count=1 seek=1000 + fdisk disk.img + # create a new primary partition spanning the whole disk: n p and just accept the defaults, and finish with w + settrans -ca disk /hurd/storeio -T typed file:disk.img + settrans -ca disk1 /hurd/storeio -T typed part:1:file:disk.img + /sbin/mke2fs disk1 + settrans -ca chroot-hurd-amd64 /hurd/ext2fs disk1 + +(here we assume that fdisk puts the partition at sector 2048, that's indeed the +current default behavior) + +Then run the same debootstrap command as above. + +You can then make the disk bootable: + + mkdir chroot-hurd-amd64/boot/grub + tee chroot-hurd-amd64/boot/grub/grub.cfg << 'EOF' + set default="0" + set timeout=5 + menuentry "Debian GNU/Hurd amd64" { + insmod ext2 + set root=(hd0,1) + multiboot /boot/gnumach-1.8-486.gz root=part:1:device:wd0 + module /hurd/pci-arbiter.static pci-arbiter \ + --host-priv-port='${host-port}' --device-master-port='${device-port}' \ + --next-task='${disk-task}' \ + '$(pci-task=task-create)' '$(task-resume)' + module /hurd/rumpdisk.static rumpdisk \ + --next-task='${fs-task}' \ + '$(disk-task=task-create)' + module /hurd/ext2fs.static ext2fs --readonly \ + --multiboot-command-line='${kernel-command-line}' \ + --exec-server-task='${exec-task}' -T typed '${root}' \ + '$(fs-task=task-create)' + module /lib/ld-x86-64.so.1 exec /hurd/exec '$(exec-task=task-create)' + } + EOF + grub-install --modules="part_msdos ext2" --boot-directory chroot-hurd-amd64/boot disk + settrans -ga chroot-hurd-amd64 + settrans -ga disk + settrans -ga disk1 + +Then boot it, and proceed like for the chroot case. + +**Creating a pbuilder chroot** + +Here is a sample `/etc/pbuilderrc`: + + MIRRORSITE=https://people.debian.org/~sthibault/tmp/hurd-amd64 + AUTOCLEANAPTCACHE=yes + EXTRAPACKAGES="eatmydata" + if [ -z "$LD_PRELOAD" ]; then + LD_PRELOAD=libeatmydata.so + else + LD_PRELOAD="$LD_PRELOAD":libeatmydata.so + fi + export LD_PRELOAD + DEBOOTSTRAPOPTS=( + '--variant=buildd' + '--force-check-gpg' + '--keyring=/usr/share/keyrings/debian-keyring.gpg' + ) + APTKEYRINGS=(/usr/share/keyrings/debian-keyring.gpg) + +And this is needed until we get the `aptitude` package built: + + sudo ln -sf pbuilder-satisfydepends-apt /usr/lib/pbuilder/pbuilder-satisfydepends + +And then you can run `sudo pbuilder create` , `sudo pbuilder login` , `pdebuild` + +**Installing from the debian-ports archive** + +For now it's quite empty (not even gcc), but it can be debootstrapped. That will be used to build packages on the buildds. + + debootstrap --foreign --verbose --arch hurd-amd64 --extra-suites=unreleased --include=debian-ports-archive-keyring --keyring=/usr/share/keyrings/debian-ports-archive-keyring.gpg sid chroot-hurd-amd64 https://deb.debian.org/debian-ports/ + +**Installing proper & more packages** + +The `people.debian.org` repository is only for bootstraping the distribution. Proper packages are getting uploaded on the usual mirror: + +``` +deb http://deb.debian.org/debian-ports sid main +deb http://deb.debian.org/debian-ports unreleased main +``` + +**Installing a 64bit system** + +In principle crosshurd should be working, one however should add this source to get more packages for now: + + deb http://people.debian.org/~sthibault/tmp/hurd-amd64 unstable + +into /etc/crosshurd/sources.list/gnu diff --git a/open_issues/Upstart.mdwn b/open_issues/Upstart.mdwn deleted file mode 100644 index 1972e197..00000000 --- a/open_issues/Upstart.mdwn +++ /dev/null @@ -1,69 +0,0 @@ -[[!meta copyright="Copyright © 2013, 2014 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]]."]]"""]] - - -[[!template id=highlight text="""/!\ Obsolete /!\ - ---- - -[[systemd|Systemd]] has almost universally replaced upstart."""]] - -Upstart is an event based init system that is GPL licensed, however upstream -contributions are under a CLA that permits proprietary relicensing. - -Most major GNU/Linux distributions are choosing systemd as their init system -instead of upstart. The original upstart developers seem to have stopped -developing it. - -The following are the words of Colin Watson on the debian-ctte@lists.debian.org -mailing list and list the requirements of a potential HURD port: - ->I haven't looked at this in much detail, and I suspect Dimitri hasn't -yet although IIRC he did express some interest in doing so. But I -haven't seen anyone else try to outline the scope of a port, so let me -try to do so for the sake of general understanding. As far as I know, -the hardest parts would be inotify, ptrace, and prctl -(PR_SET_CHILD_SUBREAPER). - ->inotify is used to notice changes to configuration files. This is -certainly helpful for users, but it isn't critical as "initctl -reload-configuration" works without it. We could probably do without -this with the aid of a dpkg trigger. - ->ptrace is used for "expect fork" and "expect daemon"; as I indicated in -another post, I think it would be preferable to avoid these in Debian -and quite possibly to compile them out. (This would mean we wouldn't be -able to translate Ubuntu jobs quite as directly, and a number of -important jobs would definitely need to be changed, but the conversion -isn't usually particularly difficult.) - ->prctl (PR_SET_CHILD_SUBREAPER) is used to make SIGCHLD notification work -properly when Upstart is supervising a user session. This isn't a -required feature and could easily be compiled out until suitable kernel -support is available (this actually seems like the sort of thing that -could be done in the Hurd without too much difficulty, but I haven't -looked into it). If absent, it might well impede the ability to do an -advanced desktop port, but it wouldn't get in the way of porting the -bulk of services. - ->There might also be odds and ends around the details of wait status -handling. - -inotify seems to be a feature that is often used in GNU/Linux programs, and -implementing the feature in the HURD seems like a better and more rewarding -option than porting the code in Upstart. - -Although many daemons double fork, that behavior seems to be dying out, and -one can comfortably ignore the "expect fork/daemon" functionality of Upstart -(and compile it out). - -[[!tag open_issue_porting]] - -See also the discussion about upstart on the [[systemd]] page. diff --git a/open_issues/adduser.mdwn b/open_issues/adduser.mdwn deleted file mode 100644 index 713a1dd3..00000000 --- a/open_issues/adduser.mdwn +++ /dev/null @@ -1,37 +0,0 @@ -[[!meta copyright="Copyright © 2008, 2009 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="adduser: posix_spawn() error=1073741826"]] - -[[!tag open_issue_porting]] - -`adduser` does work as expected, the following warnings are spurious, they just -appear when one doesn't have the nscd package. They do not appear on Linux boxes -because there posix_spawn doesn't report ENOENT for exec(). POSIX indeed says -that `if the error occurs after the calling process successfully returns, the -child process shall exit with exit status 127'. The Hurd however reports all -errors, thus the warning. - - $ sudo adduser foo - Adding user `foo' ... - Adding new group `foo' (1002) ... - posix_spawn() error=1073741826 - posix_spawn() error=1073741826 - posix_spawn() error=1073741826 - Adding new user `foo' (1002) with group `foo' ... - posix_spawn() error=1073741826 - posix_spawn() error=1073741826 - posix_spawn() error=1073741826 - posix_spawn() error=1073741826 - Creating home directory `/home/foo' ... - Copying files from `/etc/skel' ... - [...] - -Reported at [[!debbug 623199]]. diff --git a/open_issues/alarm_setitimer.mdwn b/open_issues/alarm_setitimer.mdwn index a1c8a7d3..5f121ca6 100644 --- a/open_issues/alarm_setitimer.mdwn +++ b/open_issues/alarm_setitimer.mdwn @@ -58,7 +58,7 @@ This issue was recently fixed (around January 2013). (e19a2fad70b187e5efe79768f86a1f05cb5e0390, Tue Feb 21 02:41:18 2012) <braunr> yes, fixed :) <braunr> patch committed at - http://git.savannah.gnu.org/cgit/hurd/glibc.git/log/?h=rbraun/setitimer_fix + https://git.savannah.gnu.org/cgit/hurd/glibc.git/log/?h=rbraun/setitimer_fix <youpi> and pushed to the debian package diff --git a/open_issues/anatomy_of_a_hurd_system.mdwn b/open_issues/anatomy_of_a_hurd_system.mdwn index 82f2333c..ed1aaf97 100644 --- a/open_issues/anatomy_of_a_hurd_system.mdwn +++ b/open_issues/anatomy_of_a_hurd_system.mdwn @@ -32,6 +32,9 @@ depend on GNU Mach, while other Hurd servers depend on other Hurd servers. # Bootstrap +Take a look at the [[hurd/bootstrap]] page. There is an alternative +proposal for an [[different bootstrap|open_issues/serverbootv2]]. + ## [[hurd_init]] ## Hurd Booting Process @@ -1050,12 +1053,12 @@ Actually, the Hurd has never used an M:N model. Both libthreads (cthreads) and l <teythoon> as I said, the wire format is specified, the semantics only in written form in the source <teythoon> this is an example of the ipc specification for the proc server - http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/hurd/process.defs + https://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/hurd/process.defs <crocket> teythoon, how file server interacts with file clients should be defined as a formal protocol, too. <teythoon> do you consider the ipc description a kind of formal protocol ? <crocket> - http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/hurd/process.defs can + https://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/hurd/process.defs can be considered as a formal protocol. <crocket> However, the file server protocol should be defined on top of IPC protocol. diff --git a/open_issues/arm_port.mdwn b/open_issues/arm_port.mdwn index 26e0b770..8a2bc27f 100644 --- a/open_issues/arm_port.mdwn +++ b/open_issues/arm_port.mdwn @@ -9,56 +9,152 @@ 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]]."]]"""]] -Several people have expressed interested in a port of GNU/Hurd for the ARM -architecture. +Several people have expressed interested in a port of GNU/Hurd for the +ARM architecture. Luckily a userspace port of the Hurd servers and +glibc is underway. As early as January 1, 2024 an AArch64 port is +making some progress. Sergey did some hacking on glibc, binutils, +GCC, and added some headers to GNU Mach. He was able to build the +core Hurd servers: ext2fs, proc, exec, and auth. +One would think that he would need to port GNU Mach to run the +binaries, but Sergey ran a statically linked hello world executable on +GNU/Linux, under GDB, being careful to skip over and emulate syscalls +and RPCs. The glibc port has the TLS setup, hwcaps / cpu-features, +and ifuncs. -# IRC, freenode, #hurd, 2012-07-28 +Now to some of the more technical things: - <mcsim> Has anyone heard about porting hurd and gnu/mach to arm - architecture? - <braunr> mcsim: i think so - <braunr> mcsim: why are you asking ? - <mcsim> I found an article where author stated that he has ported hurd to - arm, but I have never met this information before. - <mcsim> He wrote ethernet driver and managed to use ping command - <mcsim> author's name is Sartakov Vasily - <braunr> well that's possible, a long time ago - <braunr> and it was probably not complete enough to be merged upstream - <braunr> like many other attempts at many other things - <mcsim> Not so long. Article is dated by June 2011. - <braunr> do you have a link ? - <mcsim> Yes, but it is in Russian. - <braunr> oh - <braunr> well i don't remember him sharing that with us - <antrik> mcsim: he did some work on porting Mach, but AIUI never got it - nearly finished - <antrik> nowadays he does L4 stuff - <antrik> was also at FOSDEM +- The TLS implementation is basically complete and working. We're +using `tpidr_el0` for the thread pointer (as can be seen in the listing +above), like GNU/Linux and unlike Windows (which uses x18, apparently) +and macOS (which uses `tpidrro_el0`). We're using "Variant I" layout, as +described in "ELF Handling for Thread-Local Storage", again same as +GNU/Linux, and unlike what we do on both x86 targets. This actually +ends up being simpler than what we had for x86! The other cool thing +is that we can do `msr tpidr_el0, x0` from userspace without any +gnumach involvement, so that part of the implementation is quite a bit +simpler too. +- Conversely, while on x86 it is possible to perform "cpuid" and +identify CPU features entirely in user space, on AArch64 this requires +access to some EL1-only registers. On Linux and the BSDs, the kernel +exposes info about the CPU features via `AT_HWCAP` (and more recently, +`AT_HWCAP2`) auxval entries. Moreover, Linux allows userland to read +some otherwise EL1-only registers (notably for us, `midr_el1`) by +catching the trap that results from the EL0 code trying to do that, +and emulating its effect. Also, Linux exposes `midr_el1` and +`revidr_el1` values through procfs. -## IRC, freenode, #hurd, 2012-10-09 +- The Hurd does not use `auxval`, nor is gnumach involved in `execve` anyway. +So I thought the natural way to expose this info would be with an RPC, +and so in `mach_aarch64.defs` I have an `aarch64_get_hwcaps` routine that +returns the two hwcaps values (using the same bits as `AT_HWCAP{,2}`) and +the values of `midr_el1`/`revidr_el1`. This is hooked to `init_cpu_features` +in glibc, and used to initialize `GLRO(dl_hwcap)` / `GLRO(dl_hwcap2)` and +eventually to pick the appropriate ifunc implementations. - <mcsim> bootinfdsds: There was an unfinished port to arm, if you're - interested. - <tschwinge> mcsim: Has that ever been published? - <mcsim> tschwinge: I don't think so. But I have an email of that person and - I think that this could be discussed with him. +- The page size (or rather, paging granularity) is notoriously not +necessarily 4096 on ARM, and the best practice is for userland not to +assume any specific page size and always query it dynamically. GNU +Mach will (probably) have to be built support for some specific page +size, but I've cleaned up a few places in glibc where things were +relying on a statically defined page size. +- There are a number of hardware hardening features available on AArch64 +(PAC, BTI, MTE — why do people keep adding more and more workarounds, +including hardware ones, instead of rewriting software in a properly +memory-safe language...). Those are not really supported right now; all +of them would require some support form gnumach side; we'll probably +need new protection flags (`VM_PROT_BTI`, `VM_PROT_MTE`), for one thing. -## IRC, freenode, #hurd, 2012-10-10 +We would need to come up with a design for how we want these to work +Hurd-wide. For example I imagine it's the userland that will be +generating PAC keys (and settings them for a newly exec'ed task), +since gnumach does not contain the functionality to generate random +values (nor should it); but this leaves an open question of what +should happen to the early bootstrap tasks and whether they can start +using PAC after initial startup. - <tschwinge> mcsim: If you have a contact to the ARM porter, could you - please ask him to post what he has? - <antrik> tschwinge: we all have the "contact" -- let me remind you that he - posted his questions to the list... +- Unlike on x86, I believe it is not possible to fully restore +execution context (the values of all registers, including `pc` and +`cpsr`) purely in userland; one of the reasons for that being that we +can apparently no longer do a load from memory straight into `pc`, +like it was possible in previous ARM revisions. So the way `sigreturn +()` works on Linux is of course they have it as a syscall that takes a +`struct sigcontext`, and writes it over the saved thread state, which +is similiar to `thread_set_state ()` in Mach-speak. The difference +being that `thread_set_state ()` explicitly disallows you to set the +calling thread's state, which makes it impossible to use for +implementing `sigreturn ()`. So I'm thinking we should lift that +restriction; there's no reason why `thread_set_state ()` cannot be +made to work on the calling thread; it only requires some careful +coding to make sure the return register (`%eax`/`%rax`/`x0`) is *not* +rewritten with `mach_msg_trap`'s return code, unlike normally. +But other than that, I do have an AArch64 versions of `trampoline.c` +and `intr-msg.h` (complete with `SYSCALL_EXAMINE` & +`MSG_EXAMINE`). Whether they work, we'll only learn once we have +enough of the Hurd running to have the proc server. -## IRC, freenode, #hurd, 2012-10-17 +MIG seems to just work (thanks to all the Flávio's work!). We are +using the `x86_64` ABI, and I have not seen any issues so far — +neither compiler errors / failed static assertions (about struct sizes +and such), nor hardware errors from misaligned accesses. - <mcsim> tschwinge: Hello. The person who I wrote regarding arm port of - gnumach still hasn't answered. And I don't think that he is going to - answer. +To bootstrap gnumach someone must fix the console, set up the virtual +memory, thread states, context switches, irqs and userspace entry +points, etc. + +Also, there is a bunch of design work to do. + +Will/can AArch64 use the same mechanism for letting userland handle +interrupts? Do we have all the mechanisms required for userland to +poke at specific addresses in memory (to replace I/O ports)? — I +believe we do, but I haven't looked closely. + +AFAIK there are no I/O ports in ARM, the usual way to configure things +is with memory-mapped registers, so this might be easy. About IRQs, +probably it needs to be arch-specific anyway. + +What should the API for manipulating PAC keys look like? Perhaps it +should be another flavor of thread state, but then it is really +supposed to be per-task, not per-thread. Alternatively, we could add a +few aarch64-specific RPCs in `mach_arrch64.defs` to read and write the +PAC keys. But also AFAICS Mach currently has no notion of per-task +arch-specific data (unlike for threads, and other than the VM map), so +it'd be interesting to add one. Could it be useful for something +else? + +What are the debugging facilities available on ARM / AArch64? Should +we expose them as more flavors of thread state, or something else? +What would GDB need? + +Should gnumach accept tagged addresses (like `PR_SET_TAGGED_ADDR_CTRL` +on Linux)? + +Can we make Linux code (in-Mach drivers, pfinet, netdde, ...) work on +AArch64? + +One can trivially port pfinet to AArch64. Eventually, we should fix +any remaining issues with lwip. That way we can stop spending time +maintaining pfinet, which is Linux's old abandoned networking stack. + +Developers will have a difficult time porting the in-Mach drivers +(arm64 was probably not even a thing at the time). We can perhaps +port Netdde, but we should instead get our userspace drivers from a +rumpkernel. + +Starting the kernel itself should be easy, thanks to GRUB, but it +shouldn't be too hard to add support for U-Boot either if needed. + +I think more issues might come out setting up the various pieces of +the system. For example, some chips have heterogeneous cores, +(e.g. mine has two A72 cores and four A53 cores) so SMP will be more +complicated. + +Also, about the serial console, it might be useful at some point to +use a driver from userspace, if we can reuse some drivers from netbsd +or linux, to avoid embedding all of them in gnumach. # IRC, freenode, #hurd, 2012-11-15 diff --git a/open_issues/automatic_backtraces_when_assertions_hit.mdwn b/open_issues/automatic_backtraces_when_assertions_hit.mdwn deleted file mode 100644 index df7294e9..00000000 --- a/open_issues/automatic_backtraces_when_assertions_hit.mdwn +++ /dev/null @@ -1,79 +0,0 @@ -[[!meta copyright="Copyright © 2010, 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]]."]]"""]] - -[[!tag open_issue_glibc]] - - -# IRC, unknown channel, unknown date - - <azeem> tschwinge: ext2fs.static: thread-cancel.c:55: hurd_thread_cancel: Assertion `! __spin_lock_locked (&ss->critical_section_lock)' failed. - <youpi> it'd be great if we could have backtraces in such case - <youpi> at least just the function names - <youpi> and in this case (static), just addresses would be enough - - -# IRC, freenode, #hurd, 2012-07-19 - -In context of the [[ext2fs_libports_reference_counting_assertion]]. - - <braunr> pinotree: tschwinge: do you know if our packages are built with - -rdynamic ? - <pinotree> braunr: debian's cflags don't include it, so unless the upstream - build systems do, -rdynamic is not added - <braunr> i doubt glibc' backtrace() is able to find debugging symbol files - on its own - <pinotree> what do you mean? - <braunr> the port reference bug youpi noticed is rare - <pinotree> even on linux, a program compiled with normal optimizations (eg - -O2 -g) can give just pointer values in backtrace()'s output - <braunr> core dumps are unreliable at best - -[[crash_server]]. - - <braunr> uh, no, backtrace does give names - <braunr> but not with -fomit-frame-pointer - <braunr> unless the binary is built with -rdynamic - <braunr> at least it used to - <pinotree> not really, when being optimized some steps can be optimized - away (eg inlines) - <braunr> that's ok - <braunr> anyway, the point is i'd like a way that can give us as much - information as possible when the problem happens - <braunr> the stack trace being the most useful imo - <pinotree> do you face issues currently with backtrace()? - <braunr> not tried yet - <braunr> i guess i could make the application trap in the kernel, and fault - there, so we can attach gdb while still in the pager address space :> - <pinotree> that would imply the need for interactivity when the fault - happens, wouldn't it? - <braunr> no - <braunr> it would remain this way until someone comes, hours, days later - <braunr> pinotree: well ok, it would require interactivity, but not *when* - it happens ;p - <braunr> pinotree: right, it needs -rdynamic - - -## IRC, freenode, #hurd, 2012-07-21 - - <braunr> tschwinge: my current "approach" is to introduce an infinite loop - <braunr> it makes the faulting task mapped in often enough to use gdb - through qemu - <braunr> ... :) - <tschwinge> My understanding is that glibc already does have some mechanism - for that: I have seen it print backtraces whendetecting malloc - inconsistencies (double free and the lite). - <braunr> yes, i thought it used the backtrace functions internally though - <braunr> that is, execinfo - <braunr> but this does require -rdynamic - - -# GCC's libbacktrace - -Introduced in GCC commit ecd3459e7bb829202601e3274411135a15c64dde. diff --git a/open_issues/bash.mdwn b/open_issues/bash.mdwn index f6b14a08..a8a71810 100644 --- a/open_issues/bash.mdwn +++ b/open_issues/bash.mdwn @@ -46,14 +46,3 @@ After having noticed that this error doesn't occur if starting *bash* with bash: start_pipeline: pgrp pipe: (ipc/mig) wrong reply message ID So, there's something different with stdout in / after the SIGINT handler. - - -# IRC, freenode, #hurd, 2013-01-13 - -Perhaps completely unrelated to the issue above, perhaps not. - - <tschwinge> bash: xmalloc: ../../../bash/lib/sh/strtrans.c:60: cannot - allocate 261 bytes (323584 bytes allocated) - <tschwinge> 1.5 GiB RAM were free. - <tschwinge> This happened when I did a rever history search (C-r [...]), - and then pressed C-c. diff --git a/open_issues/bcachefs.mdwn b/open_issues/bcachefs.mdwn new file mode 100644 index 00000000..aa39bce0 --- /dev/null +++ b/open_issues/bcachefs.mdwn @@ -0,0 +1,326 @@ +[[!meta copyright="Copyright © 2007, 2008, 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]]."]]"""]] + +[[!tag open_issue_hurd]] + +The Hurd's primary filesystem is ext2, which works but lacks modern +features. With ext2, Hurd users reguarly deal with filesystem +corruption. Ext2 does not have a journal, so Hurd users occasionally +have to deal with filesystem corruption. `fsck` can fix most of the +issues (with loss of random data), but without a proper journal the +Hurd currently is not a good a OS for long-term data storage. + +Bcachefs is a modern COW (copy-on-write) open source filesystem for +Linux, which intends to replace Btrfs and ZFS while having the +performance of ext4 or XFS. It is almost 100,000 lines of code. +Btrfs is 150,000 lines of code. Bcachefs is structured as a +filesystem built on top of a database. There is a clean small +database transaction layer. That core database library is maybe +25,000 lines of code. + +Some Hurd developers recently [[talked with +Bcachefs|https://youtube.com/watch?v=bcWsrYvc5Fg]] author Kent +Overstreat about porting bcachefs to the Hurd. There are currently no +concrete plans to do so due to lack of developer man power. + +90% of the Bcachefs filesystem code builds and runs in userspace. It +uses a shim layer that makes maps kernel locking primatives to +pthreads, the kernel io API is mapped to AIO, etc. Bcachefs does +intend to eventually rewrite most or all of its current codebase into +rust. + +Kent is ok with us merging a shim layer for libstore that maps to the +Unix filesystem API. That would be a header file that goes into the +bcachefs code. + +There is a somewhat working FUSE port of bcachefs, but Kent is not +certain that is a good way to run bcachefs in userspace. Kent wants +to use the FUSE port to help in debbugging. Suppose bcachefs starts +acting up, then you could switch to running it in userspace and attach +GDB to the running process. This is currently not possible. + +We could port bcachefs to the Hurd's native filesystem API: libdiskfs. + +One interesting aspect of the conversation was Kent's goal of re-using +kernel code in userspace. The Linux kernel hashtable code is high +performance, resizeable, lockless, and builds and runs in userspace. +As long as you have liburcu, then you can use the kernel hashtable in +userspace on the Hurd. This might be useful to use on the Hurd. + +Bcachefs is liscensed as GPLv2, and many of Kent's previous employers +own the patents, including Google. Kent is ok with potentially making +the license GPLv2+, as long as there was not a promise to keep +bcachefs GPLv2 only. + +# IRC logs + +https://logs.guix.gnu.org/hurd/2023-09-26.log + + <solid_black> maybe I'm wrong though, do you know much about fuse? or file systems? + <damo22> no i dont know much about filesystems + <damo22> what is bcachefs? + <solid_black> see? :D + <azert> I agree that someone intimate in the Mach pager api, libdiskfs and fuse would be great at that meeting + <solid_black> I do kind of understand Mach VM / paging, I must say + <solid_black> from the looks of it, I even understand it best among those who have looked at it recently + <solid_black> and I mostly understand libdiskfs + <damo22> so go to the meeting + <damo22> what is fuse? do we even need it for hurd? + <damo22> file systems in userspace + <solid_black> FUSE is "filesystem in user space", it's both the name for the concept, and the name of Linux's specific mechanism, of offloading fs to userland + <damo22> yeah, i think it may be unneeded for filesystem on hurd + <solid_black> it's basically a giant hack that pretends to be a fileystem implementation to the rest of the kernel, and then sends requests and receives responses from a userland program that _actually_ implements the fs + <solid_black> on the Hurd, *of course* filesystems are implemented in userland, that's the only and tnhe natural way everything works + <solid_black> but that's where the similarities end + <solid_black> you cannot just take a linux fuse fs, using libfuse, and run it on the Hurd + <solid_black> there has been a project make a library that would have the same API as libfuse, but act as a Hurd translator, specifically to facilitate porting linux filesystems + <damo22> i imagine fuse has an api + <solid_black> last I heard, it was never completed, but who knows + <solid_black> it has a kerne <->userland protocol and a userspace library (libfuse) for implementing that protocol, yes + <damo22> solid_black: you seem to know more about fuse than you admitted + <solid_black> https://www.gnu.org/software/hurd/hurd/libfuse.html + <solid_black> I know the basics, around as much as I have just told you + <azert> I think that gnucode idea was that this would be the easiest to port bcachefs to the Hurd, but I doubt it would be the best + <solid_black> I have also hacked on a C++ fuse fs (darling-dmg), though I don't think I interacted with the fuse parts of it much + <azert> Or even the easier + <solid_black> yeah, I don't think it'd be the best or the easiest one either + <damo22> if someone implemented libfuse api and made it as a hurd translator, surely it would work natively? + <damo22> <braunr> zacts: the main problem seems to be the interactions between the fuse file system and virtual memory (including caching) + <braunr> something the hurd doesn't excel at + <braunr> it *may* be possible to find existing userspace implementations that don't use the system cache (e.g. implement their own) + <azert> Yes, that’s a possibility that needs to be kept open for discussion + <nikolar> Sounds interesting + <solid_black> youpi: ping + <youpi> pong + <solid_black> hello! + <solid_black> any thoughts on the above discussion? are you going to participate in the call that's being set up? + <youpi> I don't have time for it + <youpi> (AFAIK the fuse hurd implementation does work to some extent) + <solid_black> I should at least try out Hurd's fuse before the call, good idea + <solid_black> maybe read up on the Linux's fuse + <solid_black> thoughts on using fuse vs libdiskfs for bcachefs? + <youpi> using fuse would probably be less work + <youpi> and it'd probably mean fixing things in libfuse, which can benefit many other FS anyway + <solid_black> is it true that the "low level" API of libfuse is unimplemented and unimplementable? + <youpi> I don't know what that "low level" API is + <solid_black> this IIUC https://github.com/libfuse/libfuse/blob/master/include/fuse_lowlevel.h + <solid_black> > libfuse offers two APIs: a "high-level", synchronous API, and a "low-level" asynchronous API. In both cases, incoming requests from the kernel are passed to the main program using callbacks. When using the high-level API, the callbacks may work with file names and paths instead of inodes, and processing of a request finishes when the callback function returns. When using the low-level API, the callbacks must work with inodes and responses must be se + <solid_black> nt explicitly using a separate set of API functions. + <youpi> where did you read that it'd be unimplementable ? + <solid_black> https://git.savannah.gnu.org/cgit/hurd/incubator.git/tree/README?h=libfuse/master + <solid_black> > This is simply because it is to specific to the Linux kernel and (besides that) it is not farly used now. + <youpi> In case the latter should change in the future, we might want to re-think about that issue though. + <solid_black> so, sounds like it's perhaps implementable in theory, but that'd require additional work and design + <youpi> see the sentence below... + <solid_black> the low-level API is what bcachefs uses + <youpi> well, additional work and design, of course + <solid_black> seems to, at least, from a quick glance + <youpi> any async API needs some + <youpi> but I don't see why it would not be possible + <youpi> mig precisely supports asynchronous stubs + <solid_black> bcachefs-tools/cmd_fusermount.c is just 1274 lines, which inspires some hope + <solid_black> asynchrony is not the problem, I imagine (but I haven't looked), but being too tied to Linux might be + <youpi> it's not really tied, as in it doesn't seem to use linux-specific functions + <youpi> but it uses linux-like notions, which indeed need to be translated to the hurdish notions + <youpi> but that's not something really tough + <youpi> just needs to be worked on + +https://logs.guix.gnu.org/hurd/2023-09-27.log#103329 + + <solid_black> libfuse as shipped as Debian doesn't seem very + functional, I can't even build a simple program against it: + 'i386-gnu/libfuse.so: undefined reference to `assert'' + + <solid_black> (assert is of course a macro in glibc) + <solid_black> and it segfaults in fuse_main_real + <solid_black> lowleve fuse ops do seem to map to netfs concept nicely, as far as I can see so far + <solid_black> and (again, so far) I don't see any asynchrony in how bcachefs uses fuse, i.e. they always fuse_reply() inside the method implementation + + <solid_black> but if we had to implement low-level fuse API, this would be an issue + <solid_black> because netfs is syncronous + <solid_black> this is again a place where I don't think netfs is actually that useful + <solid_black> libfuse should be its own standalone tranlator library, a peer to lib{disk,net,triv}fs + <solid_black> yell at me if you disagree + <youpi> or perhaps make it use libdiskfs ? + <youpi> there's significant code in libdiskfs that you'd probably not want to reimplement in libfuse + <solid_black> like what? + <youpi> starting a translator + <youpi> all the posix semantic bits + <solid_black> (this is another thing, I don't believe there is a significant difference that explains libdiskfs and libnetfs being two separate libraries. but it's too late to merge them, and I'm not an fs dev) + + <solid_black> starting a translator is abstracted into libfshelp specifically so it can be easily reused? + <solid_black> is libdiskfs synchronous? + <youpi> I'm just saying things out of my memory + <solid_black> scratch that, diskfs does not work like that at all + <youpi> piece of it is in fshelp yes + <solid_black> it works on pagers, always + <youpi> but significant pieces are in libdiskfs too + <youpi> and you are saying you are not an FS person :) + <youpi> you do know libdiskfs etc. well beyond the average + <youpi> perhaps not the ext2 FS structure, but that's not really important here + <youpi> see e.g. the short-circuits in file-get-trans.c + <solid_black> I may understand how the Hurd's translator libraries work, somewhat better than the avergae person :) + <youpi> and the code around fshelp_fetch_root + <solid_black> but I don't know about how filesystems are actually organized, on-disk (beyond the basics that there any inodes and superblocks and journaled writes and btrees etc) + <youpi> you don't really need to know more about that + <solid_black> nor do I know the million little things about how filesystem code should be written to be robust and performant + <solid_black> yeah so as I was saying, libdiskfs expects files to be mappable (diskfs_get_filemap_pager_struct), and then all I/O is implemented on top of that + <solid_black> e.g. to read, libdiskfs queries that pager from the impl, maps it into memory, and copies data from there to the reply message + <solid_black> I must have mentioned that already, I'd like to rewrite that code path some day to do less copying + <solid_black> I imagine this might speed up I/O heavy workloads + <youpi> ? it doesn't copy into the reply + <youpi> it transfers map + <solid_black> it does, let me find the code + <youpi> in some corner cases yes + <youpi> but not normal case + <youpi> https://darnassus.sceen.net/~hurd-web/hurd/io_path/ + <solid_black> libdiskfs/rdwr-internal.c, it does pager_memcpy, which is a glorified memcpy + fault handling + <solid_black> don't trust that wiki page + <youpi> why not ? + <youpi> not, pager_memcpy is not just a memcpy + <youpi> it's using vm_copy whenever it can + <youpi> i.e. map transfer + <solid_black> well yes, but doesn't the regular memcpy also attempt to do that? + <youpi> it happens to do so indeed + <youpi> but that' doesn't matter: I do mean it's trying *not* copying + <youpi> by going through the mm + <youpi> note: if a wiki page is bogus, propose a fix + <solid_black> I think there was another copy on the path somewhere (in the server, there's yet another in the client of course), but I can't quite remember where + <solid_black> and I wouldn't rely on that vm_copy optimization + <solid_black> it's may be useful when it working, but we have to design for there to not be a need to make a copy in the first place + <solid_black> ah well, pager_read_page does the other copy + <youpi> when things are not aligned etC. you'll have to do a copy anyway + <solid_black> but then again, this is all my idle observations, I'm not an fs person, I haven't done any profiling, and perhaps indeed all these copies are optimized away with vm_copy + <youpi> where in pager_read_page do you see a copy? + <youpi> it should be doing a store_read + <youpi> passing the pointer to the driver + <solid_black> ext2fs/pager.c:file_pager_read_page (at line 220 here, but I haven't pulled in a while) + <solid_black> it does do a store_read, and that returns a buffer, and then it may have to copy that into the buffer it's trying to return + <solid_black> though in the common case hopefully it'll read everything in a single read op + <youpi> it's in the new_buf != *buf + offs case + <youpi> which is not supposed to be the usual case + <solid_black> but now imagine how much overhead this all is + <youpi> what? the ifs? + <solid_black> we're inside io_read, we already have a buffer where we should put the data into + <youpi> I have to go give a course, gotta go + <solid_black> we could just device_read() into there + <youpi> you also want to use a cache + <youpi> otherwise it'll be the disk that'll kill yiour performance + <youpi> so at some point you do have to copy from the cache to the application + <youpi> that's unavoidable + <youpi> or if it's large, you can vm_copy + copy-on-write + <youpi> but basically, the presence of the cache means you can have to do copies + <youpi> and that's far less costly than re-reading from the disk + <solid_black> why can't you return the cache page directly from io_read RPC? + <youpi> that's vm_copy, yes + <youpi> but then if the app modifies the piece, you have to copy-on-write + <youpi> anywauy, really gottago + <solid_black> that part is handled by Mach + <solid_black> right, so once you're back: my conclusion from looking at libfuse is that it should be rewritten, and should not be using netfs (nor diskfs), but be its own independent translator framework + <solid_black> and it just sounds like I'm going to be the one who is going to do it + <solid_black> and we could indeed use bcachefs as a testbed for the low level api, and darling-dmg for the high level api + <solid_black> I installed avfs from Debian (one of the few packages that depend on libfuse), and sure enough: avfs: symbol lookup error: /lib/i386-gnu/libfuse.so.1: undefined symbol: assert_perror + <solid_black> upstream fuse is built with Meson 🤩️ + <solid_black> I'm wondering whether this would be better done as a port in the upstream libfuse, or as a Hurd-specific libfuse lookalike that borrows some code from the upstream one (as now) + <damo22> solid_black: what is your argument to rewrite a translator framework for fuse? + <damo22> i dont understand + <solid_black> hi + <damo22> hi + <solid_black> basically, 1. while the concepts of libfuse *lowlevel* api seem to match that of hurd / netfs, they seem sufficiently different to not be easily implementable on top of netfs + <solid_black> particularly, the async-ness of it, while netfs expects you to do everything synchronously + <damo22> is that a bug in netfs? + <solid_black> this could be maybe made to work, by putting the netfs thread doing the request to sleep on a condition variable that would get signalled once the answer is provided via the fuse api... but I don't think that's going to be any nicer than designing for the asynchrony from the start + <solid_black> it's not a bug, it's just a design decision, most Hurd tranalators are structured that way + <damo22> maybe you can rewrite netfs to be asynchronous and replace it + <solid_black> i.e.: it's rare that translators use MIG_NO_REPLY + explicit reply, it's much more common to just block the thread + <solid_black> 2. the current state is not "somewhat working", it's "clearly broken" + <damo22> why not start by trying to implement rumpdisk async + <damo22> and see what parts are missing + <solid_black> wdym rumpdisk async? + <damo22> rumpdisk has a todo to make it asynchronous + <damo22> let me find the stub + <damo22> * FIXME: + <damo22> * Long term strategy: + <damo22> * + <damo22> * Call rump_sys_aio_read/write and return MIG_NO_REPLY from + <damo22> * device_read/write, and send the mig reply once the aio request has + <damo22> * completed. That way, only the aio request will be kept in rumpdisk + <damo22> * memory instead of a whole thread structure. + <solid_black> ah right, that reminds me: we still don't have proper mig support for returning errors asynchronously + <damo22> if the disk driver is not asynchronous, what is the point of making the filesystem asynchronous? + <solid_black> the way this works, being asynchronous or not is an implementatin detail of a server + <solid_black> it doesn't matter to others, the RPC format is the same + <solid_black> there's probably not much point in asynchrony for a real disk fs like bcachefs, which must be why they don't use it and reply immediately + <solid_black> but imagine you're implementing an over-the-network fs with fuse, then you'd want asynchrony + <damo22> what is your goal here? do you want to fix libfuse? + <solid_black> I don't know + <solid_black> I'm preparing for the call with Kent + <solid_black> but it looks like I'm going to have to rewrite libfuse, yes + <damo22> possibly the caching is important + <damo22> ie, where does it happen + <solid_black> maybe, yes + <solid_black> does fuse support mmap? + <damo22> idk + <damo22> good q for kent + <solid_black> one essential fs property is coherence between mmap and r/w + <solid_black> so it you change a byte in an mmaped file area, a read() of that byte after that should already return the new value + <solid_black> same for write() + read from memory + <solid_black> this is why libdiskfs insists on reading/writing files via the pager and not via callbacks + <solid_black> I wonder how fuse deals with this + <damo22> good point, no idea + <solid_black> does fuse really make the kernel handle O_CREAT / O_EXCL? I can't imagine how that would work without racing + <solid_black> guess it could be done by trying opening/creating in a loop, if creation itself is atomic, but this is not nice + <damo22> something is still slowing down smp + <damo22> it cant possibly be executing as fast as possible on all cores + <damo22> if more cores are available to run threads, it should boot faster not slower + <azert> Hi damo22, your reasoning would hold if the kernel wouldn’t be “wasting” most of its time running in kernel mode tasks + <azert> If replacing CPU_NUMBER by a better implementation gave you a two digits improvement, that kind of implies that the kernel is indeed taking most of the cpu + <damo22> yes i mean, something in the kernel is slowing down smp + <azert> What about vm_map and all thread tasks synchronization + <azert> ? + <damo22> i dont understand how the scheduler can halt the APs in machine_idle() and not end up wasting time + <damo22> how does anything ever run after HLT + <damo22> in that code path + <damo22> if the idle thread halts the processor the only way it can wake up is with an interrupt + <damo22> but then, does MARK_CPU_ACTIVE() ever run? + <damo22> hmm it does + <azert> I think that normally the cpu would be running scheduler code and get a thread by itself. + <damo22> thats not how it works + <damo22> most of the cpus are in idle_continue + <damo22> then on a clock interrupt or ast interrupt, they are woken to choose a thread i think + <damo22> s/choose/run + <azert> If they are in cpu_idle then that’s what happens, yea + <azert> But normally they wouldn’t be in cpu idle but running the schedule and just a thread on their own + <azert> Cpu_idle basically turns off the cpu + <azert> To save power + <damo22> every time i interrupt the kernel debugger, its in cpu-idle + <damo22> i dont know if it waits until it is in that state so maybe thats why + <azert> That means that there is nothing to schedule + <azert> Or yea that’s another explanation + <damo22> yes, exactly i think it is seemingly running out of threads to schedule + <azert> A bug in the debugger + <damo22> i need to print the number of threads in the queue + <youpi> adding a show subcommand for the scheduler state would probably be useful + <youpi> solid_black: btw, about copies, there's a todo in rumpdisk's rumpdisk_device_read : /* directly write at *data when it is aligned */ + <solid_black> youpi: indeed, that looks relevant, and wouldn't be hard to do + <solid_black> ideally, it should all be zero-copy (or: minimal number of copies), from the device buffer (DMA? idk how this works, can dma pages be then used as regular vm pages?) all the way to the data a unix process receives from read() or something like that + <solid_black> without "slow" memcpies, and ideally with little vm_copies too, though transferring ages in Mach messages is ok + <solid_black> s/ages/pages/ + <solid_black> read() requires ones copy purely because it writes into the provided buffer (and not returns a new one), and we don't have mach_msg_overwrite + <solid_black> though again one would hope vm_copy would help there + <solid_black> ...I do think that it'd be easier to port bcachefs over to netfs than to rewrite libfuse though + <solid_black> but then nothing is going to motivate me to work on libfuse + <azert> solid_black: I never work on things that don’t motivate me somehow + <azert> Btw, if you want zerocopy for IO, I think you need to do asynchronous io + <azert> At least that’s the only way for me to make sense of zerocopy + <solid_black> I don't think sync vs async has much to do with zero-copy-ness? w + + diff --git a/open_issues/clock_gettime.mdwn b/open_issues/clock_gettime.mdwn index 407a104c..d9f05999 100644 --- a/open_issues/clock_gettime.mdwn +++ b/open_issues/clock_gettime.mdwn @@ -95,7 +95,7 @@ In context of [[select]]. ## IRC, freenode, #hurd, 2013-02-12 <braunr> pinotree: - http://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?h=rbraun/select_timeout_pthread_v2&id=6ec50e62d9792c803d00cbff1cab2c0b3675690a + https://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?h=rbraun/select_timeout_pthread_v2&id=6ec50e62d9792c803d00cbff1cab2c0b3675690a <pinotree> uh nice <pinotree> will need two small inline functions to convert time_data_t <-> timespec, but that's it diff --git a/open_issues/copyright_assignment.mdwn b/open_issues/copyright_assignment.mdwn new file mode 100644 index 00000000..bc3e66f7 --- /dev/null +++ b/open_issues/copyright_assignment.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2021 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]]."]]"""]] + +Current issues with copyright assignments: + +* David Michael never started the process. +* Kalle Olavi Niemitalo ([contribution](https://savannah.gnu.org/bugs/index.php?48930) [contribution](https://savannah.gnu.org/bugs/index.php?49056)) [does not want to assign copyright](https://lists.gnu.org/archive/html/bug-hurd/2016-10/msg00069.html) +* Olaf Buddenhagen, faced with process issues, gave up around 2016 july 23rd. +* Brent Baccala (cases #1160318 #1497319): does not want to assign all past+future changes, would rather provide code under a BSD licence, or assign copyright separately for each contribution (request-assign.changes). +* Luca Dariz (case #1803259): process ongoing, sent form on 2022 Feb 1st, got answer on Feb 11th, pending completion. +* Various main contributors consider copyright assignment an unnecessary burden, the Hurd being considered as never-to-be-key-software. diff --git a/open_issues/crt0_o_crt1_o_debug_info_relocation_invalid_symbol_index.mdwn b/open_issues/crt0_o_crt1_o_debug_info_relocation_invalid_symbol_index.mdwn deleted file mode 100644 index b94c0c1d..00000000 --- a/open_issues/crt0_o_crt1_o_debug_info_relocation_invalid_symbol_index.mdwn +++ /dev/null @@ -1,41 +0,0 @@ -[[!meta copyright="Copyright © 2010 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_glibc open_issue_gcc]] - - $ gcc -o /dev/null -x c /dev/null - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 0 has invalid symbol index 12 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 1 has invalid symbol index 13 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 2 has invalid symbol index 2 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 3 has invalid symbol index 2 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 4 has invalid symbol index 12 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 5 has invalid symbol index 14 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 6 has invalid symbol index 14 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 7 has invalid symbol index 14 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 8 has invalid symbol index 2 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 9 has invalid symbol index 2 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 10 has invalid symbol index 13 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 11 has invalid symbol index 14 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 12 has invalid symbol index 14 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 13 has invalid symbol index 14 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 14 has invalid symbol index 14 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 15 has invalid symbol index 14 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 16 has invalid symbol index 14 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 17 has invalid symbol index 14 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 18 has invalid symbol index 14 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 19 has invalid symbol index 14 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 20 has invalid symbol index 14 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 21 has invalid symbol index 14 - /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 22 has invalid symbol index 22 - /usr/lib/gcc/i486-gnu/4.4.5/../../../crt1.o: In function `_start': - (.text+0x18): undefined reference to `main' - collect2: ld returned 1 exit status - -Likewise for `-static`, `crt0.o`. diff --git a/open_issues/cvs_tasks_file.mdwn b/open_issues/cvs_tasks_file.mdwn deleted file mode 100644 index 67b64651..00000000 --- a/open_issues/cvs_tasks_file.mdwn +++ /dev/null @@ -1,18 +0,0 @@ -[[!meta copyright="Copyright © 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009 -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="CVS tasks file"]] - -[[!tag open_issue_hurd]] - -The canonical [tasks -file](http://savannah.gnu.org/cgi-bin/viewcvs/~checkout~/hurd/hurd/tasks?rev=HEAD&content-type=text/plain) -from the CVS archive. diff --git a/open_issues/emacs.mdwn b/open_issues/emacs.mdwn index e00c3d4e..15a7c761 100644 --- a/open_issues/emacs.mdwn +++ b/open_issues/emacs.mdwn @@ -12,1531 +12,34 @@ License|/fdl]]."]]"""]] [[!tag open_issue_porting]] -GNU Emacs mostly does work, however there are a few issues. - - * `dired` on a directory hangs. (Use `C-g C-g` to break the unresponsive - operation.) - - * Configuration in `src/s/`: `gnu.h` uses `bsd-common.h`. `gnu-kfreebsd.h` - uses `gnu-linux.h` -- we probably should too. - - * `gnu-linux.h` makes a few things depend on `/proc` (also see - `HAVE_PROCFS`) -- either resort to our own ways, or enhance our - [[hurd/translator/procfs]] accordingly. - - * `sysdep.c` - - * Got a hang when compiling GNU Emacs 23, when it was compiling `.el` to - `.elc` files. Looked like busy-looping inside glibc. This was not - reproducible so far. - - * Debian emacs23_23.1+1-2, grubber, (probably) busy-looping in `ext2fs` on - `/media/data` when resuming emacs23 build in `~/tmp/emacs/emacs23-*/` - (`dpkg-buildpackage -B -uc -nc 2>&1 | tee L`). No modifications to - `emacs23-*` so far, I think. Hangs always in the same place, it seems, and - reproducible. Tarred to `emacs23-23.1+1.tar.bz2` (beware: empty and - zero-permission files: - `emacs23-23.1+1/.pc/debian-site-init-el.diff/lisp/site-init.el`, - `emacs23-23.1+1/.pc/autofiles.diff/src/config.in~`). At hang-time: the - rootfs is fine (`syncfs -c -s /` works; `syncfs` involving `/media/data` - hangs). Plan: GDB on that ext2fs, and see what's hanging / locked. [[!tag - open_issue_hurd]] - +GNU Emacs works pretty well. It works beautifully in X. --- -# 2010-10-11 - -Apparently, none of the Debian emacs packages are installable at the moment. - -Try to compile bzr trunk. - -System (sort-of) crashed during build. Perhaps while / or shortly after -dumping `src/emacs`, as there was such a zero-sized file. (Log file doesn't -show anything useful.) Removed the truncated `src/emacs`, continued build: - - [...] - Compiling /home/tschwinge/tmp/emacs/trunk/lisp/cedet/srecode/mode.el - Parsing *srecode-map-tmp* (LALR)... - Parsing *srecode-map-tmp* (LALR)...done - Segmentation fault - make[2]: *** [cedet/srecode/mode.elc] Error 139 - make[2]: Leaving directory `/media/data/home/tschwinge/tmp/emacs/trunk.build/lisp' - make[1]: *** [compile-main] Error 2 - make[1]: Leaving directory `/media/data/home/tschwinge/tmp/emacs/trunk.build/lisp' - make: *** [lisp] Error 2 - -Command line: - - $ EMACSLOADPATH=/home/tschwinge/tmp/emacs/trunk/lisp LC_ALL=C /home/tschwinge/tmp/emacs/trunk.build/src/emacs -batch --no-site-file -f batch-byte-compile /home/tschwinge/tmp/emacs/trunk/lisp/cedet/srecode/mode.el - -GDB: - - Program received signal SIGSEGV, Segmentation fault. - mark_object (arg=1) at /home/tschwinge/tmp/emacs/trunk/src/alloc.c:5343 - 5343 if (STRING_MARKED_P (ptr)) - (gdb) bt - #0 mark_object (arg=1) at /home/tschwinge/tmp/emacs/trunk/src/alloc.c:5343 - #1 0x0818080f in Fgarbage_collect () at /home/tschwinge/tmp/emacs/trunk/src/alloc.c:4993 - #2 0x08196db3 in Ffuncall (nargs=1, args=0x23fce70) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2987 - #3 0x081ce8e1 in Fbyte_code (bytestr=139696577, vector=141708997, maxdepth=28) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 - #4 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 - #5 0x08196bb3 in Ffuncall (nargs=1, args=0x23fcff0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 - #6 0x081ce8e1 in Fbyte_code (bytestr=139922913, vector=141583493, maxdepth=28) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 - #7 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 - #8 0x08196bb3 in Ffuncall (nargs=3, args=0x23fd170) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 - #9 0x081ce8e1 in Fbyte_code (bytestr=140515737, vector=141583205, maxdepth=24) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 - #10 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 - #11 0x08196bb3 in Ffuncall (nargs=2, args=0x23fd2f0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 - #12 0x081ce8e1 in Fbyte_code (bytestr=139911193, vector=139312997, maxdepth=12) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 - #13 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 - #14 0x08196bb3 in Ffuncall (nargs=3, args=0x23fd460) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 - #15 0x081ce8e1 in Fbyte_code (bytestr=136508105, vector=136508125, maxdepth=20) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 - #16 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 - #17 0x08196bb3 in Ffuncall (nargs=3, args=0x23fd5e0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 - #18 0x081ce8e1 in Fbyte_code (bytestr=136508849, vector=136508869, maxdepth=20) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 - #19 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 - #20 0x08195bff in apply_lambda (fun=136508805, args=139814646, eval_flag=1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3100 - #21 0x08195ef4 in Feval (form=139814582) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2412 - #22 0x081bb206 in readevalloop (readcharfun=138475290, stream=<value optimized out>, sourcename=139636697, printflag=0, unibyte=138364586, readfun=138364586, - start=138364586, end=138364586, evalfun=<value optimized out>) at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1734 - #23 0x081bbad7 in Fload (file=140023529, noerror=138364586, nomessage=138364610, nosuffix=138364586, must_suffix=138364586) - at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1225 - #24 0x081a1357 in Frequire (feature=141037690, filename=138364586, noerror=138364586) at /home/tschwinge/tmp/emacs/trunk/src/fns.c:2694 - #25 0x08196d83 in Ffuncall (nargs=2, args=0x23fdb90) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2996 - #26 0x081ce8e1 in Fbyte_code (bytestr=140023705, vector=141489853, maxdepth=8) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 - #27 0x08196304 in Feval (form=141177630) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2358 - #28 0x081bb206 in readevalloop (readcharfun=138475290, stream=<value optimized out>, sourcename=140023785, printflag=0, unibyte=138364586, readfun=138364586, - start=138364586, end=138364586, evalfun=<value optimized out>) at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1734 - #29 0x081bbad7 in Fload (file=139743441, noerror=138364586, nomessage=138364610, nosuffix=138364586, must_suffix=138364586) - at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1225 - #30 0x081a1357 in Frequire (feature=140528330, filename=138364586, noerror=138364586) at /home/tschwinge/tmp/emacs/trunk/src/fns.c:2694 - #31 0x08196d83 in Ffuncall (nargs=2, args=0x23fe030) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2996 - #32 0x081ce8e1 in Fbyte_code (bytestr=139743489, vector=139592949, maxdepth=8) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 - #33 0x08196304 in Feval (form=139785254) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2358 - #34 0x081bb206 in readevalloop (readcharfun=138475290, stream=<value optimized out>, sourcename=139743569, printflag=0, unibyte=138364586, readfun=138364586, - start=138364586, end=138364586, evalfun=<value optimized out>) at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1734 - #35 0x081bbad7 in Fload (file=139985769, noerror=138364586, nomessage=138364610, nosuffix=138364586, must_suffix=138364586) - at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1225 - #36 0x081a1357 in Frequire (feature=140528282, filename=138364586, noerror=138364586) at /home/tschwinge/tmp/emacs/trunk/src/fns.c:2694 - #37 0x08196d83 in Ffuncall (nargs=2, args=0x23fe5c4) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2996 - #38 0x0819879e in Fapply (nargs=2, args=0x23fe5c4) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2453 - #39 0x08196e26 in Ffuncall (nargs=3, args=0x23fe5c0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2971 - #40 0x081ce8e1 in Fbyte_code (bytestr=139665665, vector=140243293, maxdepth=12) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 - #41 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 - #42 0x08196bb3 in Ffuncall (nargs=2, args=0x23fe730) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 - #43 0x081ce8e1 in Fbyte_code (bytestr=139663633, vector=140113917, maxdepth=16) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 - #44 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 - #45 0x08196bb3 in Ffuncall (nargs=2, args=0x23fe8a0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 - #46 0x081ce8e1 in Fbyte_code (bytestr=139651313, vector=141733317, maxdepth=16) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 - #47 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 - #48 0x08196bb3 in Ffuncall (nargs=1, args=0x23fea20) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 - #49 0x081961cd in Feval (form=142062606) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2324 - #50 0x08198ec2 in internal_lisp_condition_case (var=139619738, bodyform=142062606, handlers=142059126) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:1407 - #51 0x081cdb3a in Fbyte_code (bytestr=139651065, vector=138947149, maxdepth=64) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:869 - #52 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 - #53 0x08196bb3 in Ffuncall (nargs=3, args=0x23fed10) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 - #54 0x081ce8e1 in Fbyte_code (bytestr=139638617, vector=140190309, maxdepth=32) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 - #55 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 - #56 0x08195bff in apply_lambda (fun=141815293, args=139024998, eval_flag=1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3100 - #57 0x08195ef4 in Feval (form=139025038) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2412 - #58 0x08198ec2 in internal_lisp_condition_case (var=138727490, bodyform=139025038, handlers=138994086) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:1407 - #59 0x081cdb3a in Fbyte_code (bytestr=141397873, vector=139422605, maxdepth=12) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:869 - #60 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 - #61 0x08196bb3 in Ffuncall (nargs=2, args=0x23ff150) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 - #62 0x081ce8e1 in Fbyte_code (bytestr=141396361, vector=138448733, maxdepth=20) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 - #63 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 - #64 0x08196bb3 in Ffuncall (nargs=1, args=0x23ff2d0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 - #65 0x081ce8e1 in Fbyte_code (bytestr=136699577, vector=136699597, maxdepth=40) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 - #66 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 - #67 0x08196bb3 in Ffuncall (nargs=2, args=0x23ff460) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 - #68 0x081ce8e1 in Fbyte_code (bytestr=136685793, vector=136685813, maxdepth=28) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 - #69 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 - #70 0x08196bb3 in Ffuncall (nargs=1, args=0x23ff5e0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 - #71 0x081ce8e1 in Fbyte_code (bytestr=136683265, vector=136683285, maxdepth=24) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 - #72 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 - #73 0x08195bff in apply_lambda (fun=136683245, args=138364586, eval_flag=1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3100 - #74 0x08195ef4 in Feval (form=138740766) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2412 - #75 0x0812dd83 in top_level_2 () at /home/tschwinge/tmp/emacs/trunk/src/keyboard.c:1336 - #76 0x081951dc in internal_condition_case (bfun=0x812dd70 <top_level_2>, handlers=138394034, hfun=0x8132020 <cmd_error>) - at /home/tschwinge/tmp/emacs/trunk/src/eval.c:1460 - #77 0x08131de5 in top_level_1 (ignore=138364586) at /home/tschwinge/tmp/emacs/trunk/src/keyboard.c:1344 - #78 0x081952a9 in internal_catch (tag=138392170, func=0x8131d80 <top_level_1>, arg=138364586) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:1204 - #79 0x08131e53 in command_loop () at /home/tschwinge/tmp/emacs/trunk/src/keyboard.c:1299 - #80 0x0813220a in recursive_edit_1 () at /home/tschwinge/tmp/emacs/trunk/src/keyboard.c:929 - #81 0x08132332 in Frecursive_edit () at /home/tschwinge/tmp/emacs/trunk/src/keyboard.c:991 - #82 0x0812727b in main (argc=<value optimized out>, argv=0x23ffad8) at /home/tschwinge/tmp/emacs/trunk/src/emacs.c:1718 - -Next: restarted from scratch, rebuilt without optimizations. -`--prefix=$PWD.install --build=i686-pc-gnu --enable-asserts ---enable-checking=all CFLAGS=-g` - - $ make - [...] - Dumping under the name emacs [sits here for a long time] - - $ vmstat - pagesize: 4K - size: 324M - free: 9.16M - active: 56M - inactive: 242M - wired: 17.6M - zero filled: 8.75G - reactivated: 0 - pageins: 289M - pageouts: 371M - page faults: 12508128 - cow faults: 1411724 - memobj hit ratio: 99% - swap size: 512M - swap free: 512M - -Apparently low memory, but doesn't swap out. - -Uses a lot of CPU time, as observed with `xm top`. - -Creating another `screen` window as user tschwinge doesn't get to the shell -prompt. - -Running `vmstat` works in a `screen` window that is already open, but running -`ps -Af` just hangs; adding `-M` helps. - -Perhaps the /media/data/ file system (which backs /home/) is in a inconsistent -state / deadlocked? - -More specifically, this does not work / does not exit: - - login> syncfs -s -c /media/data/ & - [2] 10785 - -But this works: - - login> syncfs -s -c / & - [3] 10786 - login> - [3]+ Done syncfs -s -c / - -Thus, the rootfs still is responsive; /media/data/ is not. - - login> ps -F hurd-long -T -M -w -A & - [4] 10796 - login> PID TH# UID PPID PGrp Sess TH Vmem RSS %CPU User System Args - 0 0 1 1 1 16 132M 1M 0.0 0:04.84 0:54.84 /hurd/proc - 0 0.0 0:00.00 0:00.13 - 1 0.0 0:00.30 0:03.55 - 2 0.0 0:00.30 0:04.21 - 3 0.0 0:00.65 0:06.88 - 4 0.0 0:00.02 0:00.31 - 5 0.0 0:00.32 0:03.72 - 6 0.0 0:00.00 0:00.23 - 7 0.0 0:00.00 0:00.03 - 8 0.0 0:00.30 0:03.17 - 9 0.0 0:00.47 0:04.69 - 10 0.0 0:00.62 0:06.42 - 11 0.0 0:00.40 0:05.91 - 12 0.0 0:00.47 0:04.18 - 13 0.0 0:00.10 0:00.73 - 14 0.0 0:00.56 0:05.97 - 15 0.0 0:00.26 0:04.61 - 1 0 1 1 1 1 146M 368K 0.0 0:00.00 0:00.03 /hurd/init root=device:hd0 - 0 0.0 0:00.00 0:00.03 - 2 - 1 1 1 7 418M 19.5M 0.0 0:00.00 0:12.16 root=device:hd0 - 0 0.0 0:00.00 0:00.00 - 1 92.6 0:00.00 46:33.66 - 2 0.0 0:00.00 0:12.07 - 3 0.0 0:00.00 0:00.05 - 4 0.0 0:00.00 0:00.02 - 5 0.0 0:00.00 0:00.00 - 6 0.0 0:00.00 0:00.01 - 3 0 1 1 1 173 409M 15.7M 0.2 4:39.39 34:08.86 ext2fs -A --multiboot-command-line=root=device:hd0 --host-priv-port=1 --device-master-port=2 -- - [165CM-exec-server-task=3 -T typed device:hd0 - 0 0.0 0:00.00 0:00.02 - 1 0.0 0:21.78 2:32.67 - 2 0.0 0:00.15 0:01.33 - 3 0.0 0:00.07 0:01.13 - 4 0.0 0:22.09 2:32.56 - 5 0.0 0:00.11 0:01.30 - 6 0.0 0:21.57 2:32.78 - 7 0.2 0:04.10 0:54.37 - 8 0.0 0:00.00 0:00.01 - 9 0.0 0:20.96 2:30.00 - 10 0.0 0:00.09 0:01.05 - 11 0.0 0:00.09 0:00.94 - 12 0.0 0:21.59 2:32.40 - 13 0.0 0:21.50 2:32.02 - 14 0.0 0:00.00 0:00.92 - 15 0.0 0:00.07 0:00.60 - 16 0.0 0:00.09 0:00.86 - 17 0.0 0:00.04 0:00.88 - 18 0.0 0:00.13 0:00.91 - 19 0.0 0:00.04 0:00.91 - 20 0.0 0:00.02 0:00.89 - 21 0.0 0:00.08 0:00.97 - 22 0.0 0:00.05 0:00.84 - 23 0.0 0:00.04 0:00.86 - 24 0.0 0:00.09 0:00.86 - 25 0.0 0:00.11 0:00.88 - 26 0.0 0:00.04 0:00.64 - 27 0.0 0:21.10 2:32.22 - 28 0.0 0:20.32 2:29.92 - 29 0.0 0:20.58 2:31.51 - 30 0.0 0:20.50 2:32.72 - 31 0.0 0:21.05 2:30.05 - 32 0.0 0:19.78 2:33.40 - 33 0.0 0:20.55 2:31.88 - 34 0.0 0:00.00 0:00.06 - 35 0.0 0:00.00 0:00.07 - 36 0.0 0:00.00 0:00.02 - 37 0.0 0:00.01 0:00.05 - 38 0.0 0:00.00 0:00.03 - 39 0.0 0:00.00 0:00.02 - 40 0.0 0:00.00 0:00.06 - 41 0.0 0:00.02 0:00.02 - 42 0.0 0:00.00 0:00.03 - 43 0.0 0:00.00 0:00.05 - 44 0.0 0:00.00 0:00.07 - 45 0.0 0:00.00 0:00.02 - 46 0.0 0:00.00 0:00.02 - 47 0.0 0:00.00 0:00.04 - 48 0.0 0:00.00 0:00.03 - 49 0.0 0:00.00 0:00.03 - 50 0.0 0:00.00 0:00.05 - 51 0.0 0:00.00 0:00.05 - 52 0.0 0:00.00 0:00.04 - 53 0.0 0:00.00 0:00.04 - 54 0.0 0:00.00 0:00.02 - 55 0.0 0:00.00 0:00.03 - 56 0.0 0:00.01 0:00.01 - 57 0.0 0:00.03 0:00.01 - 58 0.0 0:00.01 0:00.00 - 59 0.0 0:00.00 0:00.00 - 60 0.0 0:00.00 0:00.00 - 61 0.0 0:00.00 0:00.03 - 62 0.0 0:00.00 0:00.00 - 63 0.0 0:00.00 0:00.08 - 64 0.0 0:00.00 0:00.06 - 65 0.0 0:00.01 0:00.00 - 66 0.0 0:00.00 0:00.07 - 67 0.0 0:00.00 0:00.01 - 68 0.0 0:00.02 0:00.02 - 69 0.0 0:00.01 0:00.02 - 70 0.0 0:00.01 0:00.01 - 71 0.0 0:00.01 0:00.04 - 72 0.0 0:00.00 0:00.01 - 73 0.0 0:00.01 0:00.00 - 74 0.0 0:00.00 0:00.06 - 75 0.0 0:00.00 0:00.04 - 76 0.0 0:00.02 0:00.05 - 77 0.0 0:00.00 0:00.03 - 78 0.0 0:00.00 0:00.02 - 79 0.0 0:00.00 0:00.05 - 80 0.0 0:00.01 0:00.00 - 81 0.0 0:00.00 0:00.02 - 82 0.0 0:00.00 0:00.03 - 83 0.0 0:00.00 0:00.00 - 84 0.0 0:00.00 0:00.00 - 85 0.0 0:00.00 0:00.04 - 86 0.0 0:00.00 0:00.04 - 87 0.0 0:00.00 0:00.02 - 88 0.0 0:00.01 0:00.00 - 89 0.0 0:00.00 0:00.04 - 90 0.0 0:00.00 0:00.04 - 91 0.0 0:00.00 0:00.05 - 92 0.0 0:00.00 0:00.02 - 93 0.0 0:00.00 0:00.03 - 94 0.0 0:00.00 0:00.02 - 95 0.0 0:00.00 0:00.01 - 96 0.0 0:00.00 0:00.02 - 97 0.0 0:00.00 0:00.03 - 98 0.0 0:00.00 0:00.05 - 99 0.0 0:00.00 0:00.04 - 100 0.0 0:00.00 0:00.03 - 101 0.0 0:00.00 0:00.01 - 102 0.0 0:00.00 0:00.01 - 103 0.0 0:00.00 0:00.05 - 104 0.0 0:00.00 0:00.06 - 105 0.0 0:00.01 0:00.04 - 106 0.0 0:00.00 0:00.00 - 107 0.0 0:00.01 0:00.02 - 108 0.0 0:00.00 0:00.00 - 109 0.0 0:00.00 0:00.02 - 110 0.0 0:00.00 0:00.01 - 111 0.0 0:00.00 0:00.02 - 112 0.0 0:00.01 0:00.04 - 113 0.0 0:00.01 0:00.01 - 114 0.0 0:00.00 0:00.02 - 115 0.0 0:00.01 0:00.02 - 116 0.0 0:00.01 0:00.03 - 117 0.0 0:00.00 0:00.03 - 118 0.0 0:00.01 0:00.01 - 119 0.0 0:00.00 0:00.01 - 120 0.0 0:00.00 0:00.05 - 121 0.0 0:00.00 0:00.02 - 122 0.0 0:00.00 0:00.02 - 123 0.0 0:00.00 0:00.04 - 124 0.0 0:00.00 0:00.04 - 125 0.0 0:00.00 0:00.02 - 126 0.0 0:00.00 0:00.02 - 127 0.0 0:00.01 0:00.01 - 128 0.0 0:00.00 0:00.01 - 129 0.0 0:00.01 0:00.03 - 130 0.0 0:00.01 0:00.05 - 131 0.0 0:00.00 0:00.02 - 132 0.0 0:00.00 0:00.03 - 133 0.0 0:00.00 0:00.03 - 134 0.0 0:00.00 0:00.02 - 135 0.0 0:00.00 0:00.00 - 136 0.0 0:00.00 0:00.01 - 137 0.0 0:00.01 0:00.03 - 138 0.0 0:00.00 0:00.03 - 139 0.0 0:00.00 0:00.02 - 140 0.0 0:00.01 0:00.01 - 141 0.0 0:00.01 0:00.02 - 142 0.0 0:00.00 0:00.00 - 143 0.0 0:00.00 0:00.02 - 144 0.0 0:00.01 0:00.00 - 145 0.0 0:00.00 0:00.01 - 146 0.0 0:00.00 0:00.00 - 147 0.0 0:00.00 0:00.00 - 148 0.0 0:00.00 0:00.03 - 149 0.0 0:00.00 0:00.00 - 150 0.0 0:00.00 0:00.01 - 151 0.0 0:00.00 0:00.00 - 152 0.0 0:00.00 0:00.01 - 153 0.0 0:00.00 0:00.00 - 154 0.0 0:00.00 0:00.00 - 155 0.0 0:00.00 0:00.00 - 156 0.0 0:00.00 0:00.00 - 157 0.0 0:00.00 0:00.01 - 158 0.0 0:00.00 0:00.00 - 159 0.0 0:00.00 0:00.01 - 160 0.0 0:00.00 0:00.01 - 161 0.0 0:00.00 0:00.00 - 162 0.0 0:00.00 0:00.00 - 163 0.0 0:00.00 0:00.00 - 164 0.0 0:00.00 0:00.01 - 165 0.0 0:00.00 0:00.00 - 166 0.0 0:00.00 0:00.00 - 167 0.0 0:00.00 0:00.00 - 168 0.0 0:00.00 0:00.00 - 169 0.0 0:00.00 0:00.00 - 170 0.0 0:00.00 0:00.00 - 171 0.0 0:00.00 0:00.00 - 172 0.0 0:00.00 0:00.00 - 4 0 3 1 1 6 131M 1.32M 0.0 0:02.20 0:26.26 /hurd/exec - 0 0.0 0:00.43 0:05.32 - 1 0.0 0:00.41 0:05.54 - 2 0.0 0:00.44 0:05.38 - 3 0.0 0:00.00 0:00.00 - 4 0.0 0:00.45 0:05.05 - 5 0.0 0:00.44 0:04.95 - 5 0 1 1 1 6 130M 580K 0.0 0:01.17 0:14.92 /hurd/auth - 0 0.0 0:00.20 0:02.99 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.24 0:03.03 - 3 0.0 0:00.18 0:02.86 - 4 0.0 0:00.22 0:03.01 - 5 0.0 0:00.31 0:03.01 - 6 0 1 6 6 2 147M 1.09M 0.0 0:00.01 0:00.13 /bin/bash /libexec/runsystem root=device:hd0 - 0 0.0 0:00.01 0:00.13 - 1 0.0 0:00.00 0:00.00 - 7 0 3 1 1 7 130M 880K 0.1 0:00.35 0:10.10 /hurd/term /dev/console device console - 0 0.0 0:00.07 0:01.15 - 1 0.0 0:00.00 0:00.01 - 2 0.0 0:00.14 0:03.10 - 3 0.1 0:00.10 0:01.87 - 4 0.0 0:00.01 0:00.50 - 5 0.0 0:00.00 0:01.54 - 6 0.0 0:00.02 0:01.91 - 9 0 3 1 1 19 131M 1.13M 0.0 0:05.41 1:17.29 /hurd/pflocal - 0 0.0 0:00.06 0:00.48 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.05 0:00.48 - 3 0.0 0:00.78 0:09.10 - 4 0.0 0:00.49 0:06.13 - 5 0.0 0:00.56 0:07.07 - 6 0.0 0:00.30 0:03.41 - 7 0.0 0:00.47 0:05.58 - 8 0.0 0:00.27 0:06.00 - 9 0.0 0:00.04 0:00.47 - 10 0.0 0:00.43 0:06.17 - 11 0.0 0:00.70 0:09.21 - 12 0.0 0:00.00 0:00.04 - 13 0.0 0:00.59 0:10.75 - 14 0.0 0:00.14 0:01.86 - 15 0.0 0:00.04 0:01.49 - 16 0.0 0:00.02 0:00.76 - 17 0.0 0:00.22 0:05.59 - 18 0.0 0:00.16 0:02.62 - 12 0 1 12 12 6 129M 1.2M 0.0 0:00.00 0:00.06 /hurd/mach-defpager - 0 0.0 0:00.00 0:00.06 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.00 0:00.00 - 3 0.0 0:00.00 0:00.00 - 4 0.0 0:00.00 0:00.00 - 5 0.0 0:00.00 0:00.00 - 14 0 3 1 1 3 131M 504K 0.0 0:00.00 0:00.05 /hurd/storeio hd1 - 0 0.0 0:00.00 0:00.05 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.00 0:00.00 - 18 0 3 1 1 3 131M 512K 0.0 0:00.39 0:06.71 /hurd/storeio hd0 - 0 0.0 0:00.13 0:01.66 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.25 0:05.04 - 19 0 3 1 1 3 131M 656K 0.0 0:00.27 0:04.89 /hurd/storeio hd2 - 0 0.0 0:00.10 0:01.48 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.16 0:03.41 - 21 0 3 1 1 4 130M 648K 0.0 0:00.55 0:06.94 /hurd/null - 0 0.0 0:00.24 0:02.09 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.08 0:02.16 - 3 0.0 0:00.22 0:02.68 - 22 0 3 1 1 4 130M 820K 0.0 0:00.00 0:00.05 /hurd/procfs - 0 0.0 0:00.00 0:00.04 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.00 0:00.00 - 3 0.0 0:00.00 0:00.00 - 71 1 1 71 71 2 146M 728K 0.0 0:00.00 0:00.03 /usr/sbin/atd - 0 0.0 0:00.00 0:00.02 - 1 0.0 0:00.00 0:00.00 - 77 0 3 1 1 4 130M 896K 0.0 0:00.00 0:00.02 /hurd/streamio kmsg - 0 0.0 0:00.00 0:00.02 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.00 0:00.00 - 3 0.0 0:00.00 0:00.00 - 117 0 1 117 117 2 146M 1.02M 0.0 0:00.00 0:00.04 /usr/sbin/cron - 0 0.0 0:00.00 0:00.04 - 1 0.0 0:00.00 0:00.00 - 122 101 1 122 122 2 7.75M 1.07M 0.0 0:00.00 0:00.05 /usr/bin/dbus-daemon --system - 0 0.0 0:00.00 0:00.05 - 1 0.0 0:00.00 0:00.00 - 128 0 3 1 1 4 130M 908K 0.0 0:00.00 0:00.02 /hurd/fifo - 0 0.0 0:00.00 0:00.02 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.00 0:00.00 - 3 0.0 0:00.00 0:00.00 - 131 8 1 6 6 2 147M 880K 0.0 0:00.01 0:00.07 /usr/sbin/nullmailer-send -d - 0 0.0 0:00.01 0:00.07 - 1 0.0 0:00.00 0:00.00 - 139 0 3 1 1 19 133M 2.19M 0.3 0:18.66 1:17.98 /hurd/pfinet -i /dev/eth0 -a 192.168.10.63 -g 192.168.10.1 -m 255.255.255.0 - 0 0.0 0:00.01 0:00.03 - 1 0.0 0:00.00 0:00.00 - 2 0.1 0:12.72 0:14.56 - 3 0.2 0:01.65 0:12.23 - 4 0.0 0:01.67 0:18.56 - 5 0.0 0:00.50 0:05.93 - 6 0.0 0:00.40 0:06.16 - 7 0.0 0:00.57 0:05.95 - 8 0.0 0:00.30 0:04.15 - 9 0.0 0:00.15 0:01.92 - 10 0.0 0:00.13 0:01.45 - 11 0.0 0:00.14 0:01.47 - 12 0.0 0:00.07 0:01.06 - 13 0.0 0:00.08 0:01.23 - 14 0.0 0:00.08 0:00.92 - 15 0.0 0:00.03 0:00.63 - 16 0.0 0:00.03 0:00.45 - 17 0.0 0:00.05 0:00.72 - 18 0.0 0:00.03 0:00.49 - 140 0 3 1 1 3 131M 1.16M 0.0 0:00.00 0:00.05 /hurd/storeio --no-cache time - 0 0.0 0:00.00 0:00.05 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.00 0:00.00 - 142 0 1 142 142 2 10.5M 1.23M 0.0 0:00.00 0:00.05 /usr/sbin/sshd - 0 0.0 0:00.00 0:00.05 - 1 0.0 0:00.00 0:00.00 - 157 0 3 1 1 6 130M 1M 0.0 0:00.02 0:00.01 /hurd/term /dev/tty1 hurdio /dev/vcs/1/console - 0 0.0 0:00.00 0:00.00 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.00 0:00.00 - 3 0.0 0:00.00 0:00.00 - 4 0.0 0:00.00 0:00.01 - 5 0.0 0:00.01 0:00.00 - 158 0 6 158 158 2 146M 824K 0.0 0:00.00 0:00.01 /libexec/runttys - 0 0.0 0:00.00 0:00.01 - 1 0.0 0:00.00 0:00.00 - 159 0 3 1 1 15 133M 1.67M 0.0 0:00.01 0:00.06 /hurd/console - 0 0.0 0:00.01 0:00.02 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.00 0:00.00 - 3 0.0 0:00.00 0:00.00 - 4 0.0 0:00.00 0:00.01 - 5 0.0 0:00.00 0:00.00 - 6 0.0 0:00.00 0:00.00 - 7 0.0 0:00.00 0:00.02 - 8 0.0 0:00.00 0:00.00 - 9 0.0 0:00.00 0:00.00 - 10 0.0 0:00.00 0:00.00 - 11 0.0 0:00.00 0:00.00 - 12 0.0 0:00.00 0:00.01 - 13 0.0 0:00.00 0:00.00 - 14 0.0 0:00.00 0:00.00 - 160 - 158 160 160 2 147M 1.82M 0.0 0:00.02 0:00.16 -login prompt (bash) - 0 0.0 0:00.02 0:00.14 - 1 0.0 0:00.00 0:00.02 - 161 - 158 161 161 2 147M 1.78M 0.0 0:00.00 0:00.07 -login prompt (bash) - 0 0.0 0:00.00 0:00.07 - 1 0.0 0:00.00 0:00.00 - 162 - 158 162 162 2 147M 1.78M 0.0 0:00.01 0:00.07 -login prompt (bash) - 0 0.0 0:00.01 0:00.07 - 1 0.0 0:00.00 0:00.00 - 163 - 158 163 163 2 147M 1.78M 0.0 0:00.00 0:00.03 -login prompt (bash) - 0 0.0 0:00.00 0:00.03 - 1 0.0 0:00.00 0:00.00 - 164 - 158 164 164 2 147M 1.78M 0.0 0:00.02 0:00.03 -login prompt (bash) - 0 0.0 0:00.02 0:00.03 - 1 0.0 0:00.00 0:00.00 - 165 - 158 165 165 2 147M 1.78M 0.0 0:00.00 0:00.08 -login prompt (bash) - 0 0.0 0:00.00 0:00.08 - 1 0.0 0:00.00 0:00.00 - 166 - 158 166 166 2 147M 1.78M 0.0 0:00.01 0:00.01 -login prompt (bash) - 0 0.0 0:00.01 0:00.01 - 1 0.0 0:00.00 0:00.00 - 167 0 3 1 1 6 130M 1016K 0.0 0:00.01 0:00.11 /hurd/term /dev/tty2 hurdio /dev/vcs/2/console - 0 0.0 0:00.01 0:00.06 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.00 0:00.00 - 3 0.0 0:00.00 0:00.01 - 4 0.0 0:00.00 0:00.03 - 5 0.0 0:00.00 0:00.00 - 168 0 3 1 1 6 130M 1016K 0.0 0:00.00 0:00.04 /hurd/term /dev/tty3 hurdio /dev/vcs/3/console - 0 0.0 0:00.00 0:00.02 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.00 0:00.00 - 3 0.0 0:00.00 0:00.01 - 4 0.0 0:00.00 0:00.00 - 5 0.0 0:00.00 0:00.01 - 169 0 3 1 1 6 130M 1016K 0.0 0:00.00 0:00.04 /hurd/term /dev/tty5 hurdio /dev/vcs/5/console - 0 0.0 0:00.00 0:00.00 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.00 0:00.00 - 3 0.0 0:00.00 0:00.00 - 4 0.0 0:00.00 0:00.04 - 5 0.0 0:00.00 0:00.00 - 170 0 3 1 1 6 130M 1016K 0.0 0:00.00 0:00.05 /hurd/term /dev/tty4 hurdio /dev/vcs/4/console - 0 0.0 0:00.00 0:00.04 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.00 0:00.00 - 3 0.0 0:00.00 0:00.00 - 4 0.0 0:00.00 0:00.01 - 5 0.0 0:00.00 0:00.00 - 171 0 3 1 1 6 130M 1016K 0.0 0:00.00 0:00.01 /hurd/term /dev/tty6 hurdio /dev/vcs/6/console - 0 0.0 0:00.00 0:00.01 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.00 0:00.00 - 3 0.0 0:00.00 0:00.00 - 4 0.0 0:00.00 0:00.00 - 5 0.0 0:00.00 0:00.00 - 172 0 3 1 1 4 130M 892K 0.0 0:00.00 0:00.01 /hurd/password - 0 0.0 0:00.00 0:00.01 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.00 0:00.00 - 3 0.0 0:00.00 0:00.00 - 173 0 142 173 173 3 10.7M 3.09M 0.0 0:02.09 0:12.63 /usr/sbin/sshd -R - 0 0.0 0:02.09 0:12.63 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.00 0:00.00 - 174 0 3 1 1 632 2.99G 27.6M 100.3 16:43.18 52:54.41 /hurd/ext2fs /dev/hd2 - 0 0.0 0:00.01 0:00.03 - 1 0.0 0:00.00 0:00.00 - 2 0.0 1:34.24 6:26.66 - 3 0.0 0:00.04 0:00.31 - 4 0.0 0:00.13 0:00.47 - 5 0.0 0:00.05 0:00.57 - 6 0.0 1:36.91 6:26.41 - 7 0.0 0:12.98 0:34.83 - 8 0.0 1:37.85 6:26.20 - 9 0.0 1:35.07 6:17.07 - 10 0.0 0:00.05 0:00.50 - 11 0.0 0:00.04 0:00.48 - 12 0.0 0:00.07 0:00.55 - 13 0.0 0:00.03 0:00.46 - 14 0.0 0:00.03 0:00.42 - 15 0.0 0:00.06 0:00.32 - 16 0.0 0:00.05 0:00.56 - 17 0.0 0:00.05 0:00.50 - 18 0.0 0:00.05 0:00.48 - 19 0.0 0:00.03 0:00.37 - 20 0.0 0:00.08 0:00.48 - 21 0.0 0:00.01 0:00.52 - 22 0.0 0:00.02 0:00.44 - 23 0.0 0:00.02 0:00.44 - 24 0.0 0:00.03 0:00.31 - 25 0.0 0:00.05 0:00.32 - 26 0.0 0:00.04 0:00.37 - 27 0.0 0:00.00 0:00.31 - 28 0.0 0:00.03 0:00.23 - 29 0.0 0:00.05 0:00.33 - 30 0.0 0:00.04 0:00.31 - 31 0.0 0:00.01 0:00.29 - 32 0.0 0:00.07 0:00.27 - 33 0.0 0:00.05 0:00.28 - 34 0.0 0:00.04 0:00.23 - 35 0.0 0:00.04 0:00.46 - 36 0.0 0:00.02 0:00.31 - 37 0.0 0:00.02 0:00.38 - 38 0.0 0:00.06 0:00.29 - 39 0.0 0:00.03 0:00.22 - 40 0.0 0:00.02 0:00.28 - 41 0.0 0:00.03 0:00.26 - 42 0.0 0:00.05 0:00.39 - 43 0.0 0:00.06 0:00.37 - 44 0.0 0:00.03 0:00.36 - 45 0.0 0:00.04 0:00.20 - 46 0.0 0:00.02 0:00.28 - 47 0.0 0:00.01 0:00.29 - 48 0.0 0:00.03 0:00.23 - 49 0.0 0:00.04 0:00.22 - 50 0.0 0:00.07 0:00.25 - 51 0.0 0:00.00 0:00.33 - 52 0.0 0:00.05 0:00.49 - 53 0.0 0:00.02 0:00.31 - 54 0.0 0:00.00 0:00.27 - 55 0.0 0:00.06 0:00.25 - 56 0.0 0:00.05 0:00.35 - 57 0.0 0:00.01 0:00.28 - 58 0.0 0:00.06 0:00.25 - 59 0.0 0:00.05 0:00.30 - 60 0.0 0:00.03 0:00.36 - 61 0.0 0:00.04 0:00.31 - 62 0.0 0:00.05 0:00.18 - 63 0.0 0:00.02 0:00.31 - 64 0.0 0:00.00 0:00.27 - 65 0.0 0:00.02 0:00.26 - 66 0.0 0:00.00 0:00.31 - 67 0.0 0:00.00 0:00.15 - 68 0.0 0:00.04 0:00.32 - 69 0.0 0:00.04 0:00.21 - 70 0.0 0:00.01 0:00.31 - 71 0.0 0:00.05 0:00.22 - 72 0.0 0:00.01 0:00.28 - 73 0.0 0:00.04 0:00.31 - 74 0.0 0:00.06 0:00.20 - 75 0.0 0:00.04 0:00.38 - 76 0.0 0:00.03 0:00.37 - 77 0.0 0:00.06 0:00.32 - 78 0.0 0:00.04 0:00.22 - 79 0.0 0:00.04 0:00.25 - 80 0.0 0:00.04 0:00.29 - 81 0.0 0:00.07 0:00.31 - 82 0.0 0:00.04 0:00.27 - 83 0.0 0:00.04 0:00.23 - 84 0.0 0:00.02 0:00.37 - 85 0.0 0:00.03 0:00.24 - 86 0.0 0:00.01 0:00.29 - 87 0.0 0:00.03 0:00.24 - 88 0.0 0:00.01 0:00.31 - 89 0.0 0:00.03 0:00.39 - 90 0.0 0:00.00 0:00.30 - 91 0.0 0:00.03 0:00.32 - 92 0.0 0:00.00 0:00.24 - 93 0.0 0:00.03 0:00.32 - 94 0.0 0:00.04 0:00.30 - 95 0.0 0:00.00 0:00.33 - 96 0.0 0:00.02 0:00.24 - 97 0.0 0:00.01 0:00.26 - 98 0.0 0:00.04 0:00.33 - 99 0.0 0:00.03 0:00.26 - 100 0.0 0:00.05 0:00.29 - 101 0.0 0:00.05 0:00.34 - 102 0.0 0:00.04 0:00.38 - 103 0.0 0:00.00 0:00.22 - 104 0.0 0:00.03 0:00.38 - 105 0.0 0:00.01 0:00.43 - 106 0.0 0:00.03 0:00.37 - 107 0.0 0:00.05 0:00.31 - 108 0.0 0:00.02 0:00.31 - 109 0.0 0:00.00 0:00.26 - 110 0.0 0:00.03 0:00.27 - 111 0.0 0:00.03 0:00.25 - 112 0.0 0:00.02 0:00.30 - 113 0.0 0:00.05 0:00.23 - 114 0.0 0:00.02 0:00.32 - 115 0.0 0:00.02 0:00.29 - 116 0.0 0:00.04 0:00.22 - 117 0.0 0:00.04 0:00.26 - 118 0.0 0:00.02 0:00.36 - 119 0.0 0:00.03 0:00.31 - 120 0.0 0:00.04 0:00.26 - 121 0.0 0:00.05 0:00.28 - 122 0.0 0:00.01 0:00.27 - 123 0.0 0:00.03 0:00.34 - 124 0.0 0:00.03 0:00.36 - 125 0.0 0:00.02 0:00.33 - 126 0.0 0:00.04 0:00.36 - 127 0.0 0:00.00 0:00.41 - 128 0.0 0:00.02 0:00.33 - 129 0.0 0:00.07 0:00.32 - 130 0.0 0:00.03 0:00.29 - 131 0.0 0:00.00 0:00.34 - 132 0.0 0:00.04 0:00.28 - 133 0.0 0:00.04 0:00.24 - 134 0.0 0:00.03 0:00.35 - 135 0.0 0:00.04 0:00.38 - 136 0.0 0:00.04 0:00.37 - 137 0.0 0:00.04 0:00.26 - 138 0.0 0:00.00 0:00.26 - 139 0.0 0:00.06 0:00.40 - 140 0.0 1:23.58 6:28.86 - 141 0.0 0:25.74 1:55.97 - 142 0.0 0:00.00 0:00.00 - 143 0.0 0:00.00 0:00.00 - 144 0.0 0:00.00 0:00.00 - 145 0.0 0:00.00 0:00.00 - 146 0.0 0:00.00 0:00.00 - 147 0.0 0:00.00 0:00.00 - 148 0.0 0:00.00 0:00.00 - 149 0.0 0:00.00 0:00.00 - 150 0.0 0:00.00 0:00.00 - 151 0.0 0:00.00 0:00.00 - 152 0.0 0:00.00 0:00.00 - 153 0.0 0:00.00 0:00.00 - 154 0.0 0:00.00 0:00.00 - 155 0.0 0:00.00 0:00.00 - 156 0.0 0:00.00 0:00.00 - 157 0.0 0:00.00 0:00.00 - 158 0.0 0:00.00 0:00.00 - 159 0.0 0:00.00 0:00.00 - 160 0.0 0:00.00 0:00.00 - 161 0.0 0:00.00 0:00.00 - 162 0.0 0:00.00 0:00.00 - 163 0.0 0:00.00 0:00.00 - 164 0.0 0:00.00 0:00.00 - 165 0.0 0:00.00 0:00.00 - 166 0.0 0:00.00 0:00.00 - 167 0.0 0:00.00 0:00.00 - 168 0.0 0:00.00 0:00.00 - 169 0.0 0:00.00 0:00.00 - 170 0.0 0:00.00 0:00.00 - 171 0.0 0:00.00 0:00.00 - 172 0.0 0:00.00 0:00.00 - 173 0.0 0:00.00 0:00.00 - 174 0.0 0:00.00 0:00.00 - 175 0.0 0:00.00 0:00.00 - 176 0.0 0:00.00 0:00.00 - 177 0.0 0:00.00 0:00.00 - 178 0.0 0:00.00 0:00.00 - 179 0.0 0:00.00 0:00.00 - 180 0.0 0:00.00 0:00.00 - 181 0.0 0:00.00 0:00.00 - 182 0.0 0:00.00 0:00.00 - 183 0.0 0:00.00 0:00.00 - 184 0.0 0:00.00 0:00.00 - 185 0.0 0:00.00 0:00.00 - 186 0.0 0:00.00 0:00.00 - 187 0.0 0:00.00 0:00.00 - 188 0.0 0:00.00 0:00.00 - 189 0.0 0:00.00 0:00.00 - 190 0.0 0:00.00 0:00.00 - 191 0.0 0:00.00 0:00.00 - 192 0.0 0:00.00 0:00.00 - 193 0.0 0:00.00 0:00.00 - 194 0.0 0:00.00 0:00.00 - 195 0.0 0:00.00 0:00.00 - 196 0.0 0:00.00 0:00.00 - 197 0.0 0:00.00 0:00.00 - 198 0.0 0:00.00 0:00.00 - 199 0.0 0:00.00 0:00.00 - 200 0.0 0:00.00 0:00.00 - 201 0.0 0:00.00 0:00.00 - 202 0.0 0:00.00 0:00.00 - 203 0.0 0:00.00 0:00.00 - 204 0.0 0:00.00 0:00.00 - 205 0.0 0:00.00 0:00.00 - 206 0.0 0:00.00 0:00.00 - 207 0.0 0:00.00 0:00.00 - 208 0.0 0:00.00 0:00.00 - 209 0.0 0:00.00 0:00.00 - 210 0.0 0:00.00 0:00.00 - 211 0.0 0:00.00 0:00.00 - 212 0.0 0:00.00 0:00.00 - 213 0.0 0:00.00 0:00.00 - 214 0.0 0:00.00 0:00.00 - 215 0.0 0:00.00 0:00.00 - 216 0.0 0:00.00 0:00.00 - 217 0.0 0:00.00 0:00.00 - 218 0.0 0:00.00 0:00.00 - 219 0.0 0:00.00 0:00.00 - 220 0.0 0:00.00 0:00.00 - 221 0.0 0:00.00 0:00.00 - 222 0.0 0:00.00 0:00.00 - 223 0.0 0:00.00 0:00.00 - 224 0.0 0:00.00 0:00.00 - 225 0.0 0:00.00 0:00.00 - 226 0.0 0:00.00 0:00.00 - 227 0.0 0:00.00 0:00.00 - 228 0.0 0:00.00 0:00.00 - 229 0.0 0:00.00 0:00.00 - 230 0.0 0:00.00 0:00.00 - 231 0.0 0:00.00 0:00.00 - 232 0.0 0:00.00 0:00.00 - 233 0.0 0:00.00 0:00.00 - 234 0.0 0:00.00 0:00.00 - 235 0.0 0:00.00 0:00.00 - 236 0.0 0:00.00 0:00.00 - 237 0.0 0:00.00 0:00.00 - 238 0.0 0:00.00 0:00.00 - 239 0.0 0:00.00 0:00.00 - 240 0.0 0:00.00 0:00.00 - 241 0.0 0:00.00 0:00.00 - 242 0.0 0:00.00 0:00.00 - 243 0.0 0:00.00 0:00.00 - 244 0.0 0:00.00 0:00.00 - 245 0.0 0:00.00 0:00.00 - 246 0.0 0:00.00 0:00.00 - 247 0.0 0:00.00 0:00.00 - 248 0.0 0:00.00 0:00.00 - 249 0.0 0:00.00 0:00.00 - 250 0.0 0:00.00 0:00.00 - 251 0.0 0:00.00 0:00.00 - 252 0.0 0:00.00 0:00.00 - 253 0.0 0:00.00 0:00.00 - 254 0.0 0:00.00 0:00.00 - 255 0.0 0:00.00 0:00.00 - 256 0.0 0:00.00 0:00.00 - 257 0.0 0:00.00 0:00.00 - 258 0.0 0:00.00 0:00.00 - 259 0.0 0:00.00 0:00.00 - 260 0.0 0:00.00 0:00.00 - 261 0.0 0:00.00 0:00.00 - 262 0.0 0:00.00 0:00.00 - 263 0.0 0:00.00 0:00.00 - 264 0.0 0:00.00 0:00.00 - 265 0.0 0:00.00 0:00.00 - 266 0.0 0:00.00 0:00.00 - 267 0.0 0:00.00 0:00.00 - 268 0.0 0:00.00 0:00.00 - 269 0.0 0:00.00 0:00.00 - 270 0.0 0:00.00 0:00.00 - 271 0.0 0:00.00 0:00.00 - 272 0.0 0:00.00 0:00.00 - 273 0.0 0:00.00 0:00.00 - 274 0.0 0:00.00 0:00.00 - 275 0.0 0:00.00 0:00.00 - 276 0.0 0:00.00 0:00.00 - 277 0.0 0:00.00 0:00.00 - 278 0.0 0:00.00 0:00.00 - 279 0.0 0:00.00 0:00.00 - 280 0.0 0:00.00 0:00.00 - 281 0.0 0:00.00 0:00.00 - 282 0.0 0:00.00 0:00.00 - 283 0.0 0:00.00 0:00.00 - 284 0.0 0:00.00 0:00.00 - 285 0.0 0:00.00 0:00.00 - 286 0.0 0:00.00 0:00.00 - 287 0.0 0:00.00 0:00.00 - 288 0.0 0:00.00 0:00.00 - 289 0.0 0:00.00 0:00.00 - 290 0.0 0:00.00 0:00.00 - 291 0.0 0:00.00 0:00.00 - 292 0.0 0:00.00 0:00.00 - 293 0.0 0:00.00 0:00.00 - 294 0.0 0:00.00 0:00.00 - 295 0.0 0:00.00 0:00.00 - 296 0.0 0:00.00 0:00.00 - 297 0.0 0:00.00 0:00.00 - 298 0.0 0:00.00 0:00.00 - 299 0.0 0:00.00 0:00.00 - 300 0.0 0:00.00 0:00.00 - 301 0.0 0:00.00 0:00.00 - 302 0.0 0:00.00 0:00.00 - 303 0.0 0:00.00 0:00.00 - 304 0.0 0:00.00 0:00.00 - 305 0.0 0:00.00 0:00.00 - 306 0.0 0:00.00 0:00.00 - 307 0.0 0:00.00 0:00.00 - 308 0.0 0:00.00 0:00.00 - 309 0.0 0:00.00 0:00.00 - 310 0.0 0:00.00 0:00.00 - 311 0.0 0:00.00 0:00.00 - 312 0.0 0:00.00 0:00.00 - 313 0.0 0:00.00 0:00.00 - 314 0.0 0:00.00 0:00.00 - 315 0.0 0:00.00 0:00.00 - 316 0.0 0:00.00 0:00.00 - 317 0.0 0:00.00 0:00.00 - 318 0.0 0:00.00 0:00.00 - 319 0.0 0:00.00 0:00.00 - 320 0.0 0:00.00 0:00.00 - 321 0.0 0:00.00 0:00.00 - 322 0.0 0:00.00 0:00.00 - 323 0.0 0:00.00 0:00.00 - 324 0.0 0:00.00 0:00.00 - 325 0.0 0:00.00 0:00.00 - 326 0.0 0:00.00 0:00.00 - 327 0.0 0:00.00 0:00.00 - 328 0.0 0:00.00 0:00.00 - 329 0.0 0:00.00 0:00.00 - 330 0.0 0:00.00 0:00.00 - 331 0.0 0:00.00 0:00.00 - 332 0.0 0:00.00 0:00.00 - 333 0.0 0:00.00 0:00.00 - 334 0.0 0:00.00 0:00.00 - 335 0.0 0:00.00 0:00.00 - 336 0.0 0:00.00 0:00.00 - 337 0.0 0:00.00 0:00.00 - 338 0.0 0:00.00 0:00.00 - 339 0.0 0:00.00 0:00.00 - 340 0.0 0:00.00 0:00.00 - 341 0.0 0:00.00 0:00.00 - 342 0.0 0:00.00 0:00.00 - 343 0.0 0:00.00 0:00.00 - 344 0.0 0:00.00 0:00.00 - 345 0.0 0:00.00 0:00.00 - 346 0.0 0:00.00 0:00.00 - 347 0.0 0:00.00 0:00.00 - 348 0.0 0:00.00 0:00.00 - 349 0.0 0:00.00 0:00.00 - 350 0.0 0:00.00 0:00.00 - 351 0.0 0:00.00 0:00.00 - 352 0.0 0:00.00 0:00.00 - 353 0.0 0:00.00 0:00.00 - 354 0.0 0:00.00 0:00.00 - 355 0.0 0:00.00 0:00.00 - 356 0.0 0:00.00 0:00.00 - 357 0.0 0:00.00 0:00.00 - 358 0.0 0:00.00 0:00.00 - 359 0.0 0:00.00 0:00.00 - 360 0.0 0:00.00 0:00.00 - 361 0.0 0:00.00 0:00.00 - 362 0.0 0:00.00 0:00.00 - 363 0.0 0:00.00 0:00.00 - 364 0.0 0:00.00 0:00.00 - 365 0.0 0:00.00 0:00.00 - 366 0.0 0:00.00 0:00.00 - 367 0.0 0:00.00 0:00.00 - 368 0.0 0:00.00 0:00.00 - 369 0.0 0:00.00 0:00.00 - 370 0.0 0:00.00 0:00.00 - 371 0.0 0:00.00 0:00.03 - 372 0.0 0:00.00 0:00.00 - 373 0.0 0:00.00 0:00.00 - 374 0.0 0:00.00 0:00.00 - 375 0.0 0:00.00 0:00.00 - 376 0.0 0:00.00 0:00.00 - 377 0.0 0:00.00 0:00.00 - 378 0.0 0:00.00 0:00.00 - 379 0.0 0:00.00 0:00.00 - 380 0.0 0:00.00 0:00.00 - 381 0.0 0:00.00 0:00.00 - 382 0.0 0:00.00 0:00.00 - 383 0.0 0:00.00 0:00.00 - 384 0.0 0:00.00 0:00.00 - 385 0.0 0:00.00 0:00.00 - 386 0.0 0:00.00 0:00.00 - 387 0.0 0:00.00 0:00.00 - 388 0.0 0:00.00 0:00.00 - 389 0.0 0:00.00 0:00.00 - 390 0.0 0:00.00 0:00.00 - 391 0.0 0:00.00 0:00.00 - 392 0.0 0:00.00 0:00.00 - 393 0.0 0:00.00 0:00.00 - 394 0.0 0:00.00 0:00.00 - 395 0.0 0:00.00 0:00.00 - 396 0.0 0:00.00 0:00.00 - 397 0.0 0:00.00 0:00.00 - 398 0.0 0:00.00 0:00.00 - 399 0.0 0:00.00 0:00.00 - 400 0.0 0:00.00 0:00.00 - 401 0.0 0:00.00 0:00.00 - 402 0.0 0:00.00 0:00.00 - 403 0.0 0:00.00 0:00.00 - 404 0.0 0:00.00 0:00.00 - 405 0.0 0:00.00 0:00.00 - 406 0.0 0:00.00 0:00.00 - 407 0.0 0:00.00 0:00.00 - 408 0.0 0:00.00 0:00.00 - 409 0.0 0:00.00 0:00.00 - 410 0.0 0:00.00 0:00.00 - 411 0.0 0:00.00 0:00.00 - 412 0.0 0:00.00 0:00.00 - 413 0.0 0:00.00 0:00.00 - 414 0.0 0:00.00 0:00.00 - 415 0.0 0:00.00 0:00.00 - 416 0.0 0:00.00 0:00.00 - 417 0.0 0:00.00 0:00.00 - 418 0.0 0:00.00 0:00.00 - 419 0.0 0:00.00 0:00.00 - 420 0.0 0:00.00 0:00.00 - 421 0.0 0:00.00 0:00.00 - 422 0.0 0:00.00 0:00.00 - 423 0.0 0:00.00 0:00.00 - 424 0.0 0:00.00 0:00.00 - 425 0.0 0:00.00 0:00.00 - 426 0.0 0:00.00 0:00.00 - 427 0.0 0:00.00 0:00.00 - 428 0.0 0:00.00 0:00.00 - 429 0.0 0:00.00 0:00.00 - 430 0.0 0:00.00 0:00.00 - 431 0.0 0:00.00 0:00.00 - 432 0.0 0:00.00 0:00.00 - 433 0.0 0:00.00 0:00.00 - 434 0.0 0:00.00 0:00.00 - 435 0.0 0:00.00 0:00.00 - 436 0.0 0:00.00 0:00.00 - 437 0.0 0:00.00 0:00.00 - 438 0.0 0:00.00 0:00.00 - 439 0.0 0:00.00 0:00.00 - 440 0.0 0:00.00 0:00.00 - 441 0.0 0:00.00 0:00.00 - 442 0.0 0:00.00 0:00.00 - 443 0.0 0:00.00 0:00.00 - 444 0.0 0:00.00 0:00.00 - 445 0.0 0:00.00 0:00.00 - 446 0.0 0:00.00 0:00.00 - 447 0.0 0:00.00 0:00.00 - 448 0.0 0:00.00 0:00.00 - 449 0.0 0:00.00 0:00.00 - 450 0.0 0:00.00 0:00.00 - 451 0.0 0:00.00 0:00.00 - 452 0.0 0:00.00 0:00.00 - 453 0.0 0:00.00 0:00.00 - 454 0.0 0:00.00 0:00.00 - 455 0.0 0:00.00 0:00.00 - 456 0.0 0:00.00 0:00.00 - 457 0.0 0:00.00 0:00.00 - 458 0.0 0:00.00 0:00.00 - 459 0.0 0:00.00 0:00.00 - 460 0.0 0:00.00 0:00.00 - 461 0.0 0:00.00 0:00.00 - 462 0.0 0:00.00 0:00.00 - 463 0.0 0:00.00 0:00.00 - 464 0.0 0:00.00 0:00.00 - 465 0.0 0:00.00 0:00.00 - 466 0.0 0:00.00 0:00.00 - 467 0.0 0:00.00 0:00.00 - 468 0.0 0:00.00 0:00.00 - 469 0.0 0:00.00 0:00.00 - 470 0.0 0:00.00 0:00.00 - 471 0.0 0:00.00 0:00.00 - 472 0.0 0:00.00 0:00.00 - 473 0.0 0:00.00 0:00.00 - 474 0.0 0:00.00 0:00.00 - 475 0.0 0:00.00 0:00.00 - 476 0.0 0:00.00 0:00.00 - 477 0.0 0:00.00 0:00.00 - 478 0.0 0:00.00 0:00.00 - 479 0.0 0:00.00 0:00.00 - 480 0.0 0:00.00 0:00.00 - 481 0.0 0:00.00 0:00.00 - 482 0.0 0:00.00 0:00.00 - 483 0.0 0:00.00 0:00.00 - 484 0.0 0:00.00 0:00.00 - 485 0.0 0:00.00 0:00.00 - 486 0.0 0:00.00 0:00.00 - 487 0.0 0:00.00 0:00.00 - 488 0.0 0:00.00 0:00.00 - 489 0.0 0:00.00 0:00.00 - 490 0.0 0:00.00 0:00.00 - 491 0.0 0:00.00 0:00.00 - 492 0.0 0:00.00 0:00.00 - 493 0.0 0:00.00 0:00.00 - 494 0.0 0:00.00 0:00.00 - 495 0.0 0:00.00 0:00.00 - 496 0.0 0:00.00 0:00.00 - 497 0.0 0:00.00 0:00.00 - 498 0.0 0:00.00 0:00.00 - 499 0.0 0:00.00 0:00.00 - 500 0.0 0:00.00 0:00.00 - 501 0.0 0:00.00 0:00.00 - 502 0.0 0:00.00 0:00.00 - 503 0.0 0:00.00 0:00.00 - 504 0.0 0:00.00 0:00.00 - 505 0.0 0:00.00 0:00.00 - 506 0.0 0:00.00 0:00.00 - 507 0.0 0:00.00 0:00.00 - 508 0.0 0:00.00 0:00.00 - 509 0.0 0:00.00 0:00.00 - 510 0.0 0:00.00 0:00.00 - 511 0.0 0:00.00 0:00.00 - 512 0.0 0:00.00 0:00.00 - 513 0.0 0:00.00 0:00.00 - 514 0.0 0:00.00 0:00.00 - 515 0.0 0:00.00 0:00.00 - 516 0.0 0:00.00 0:00.00 - 517 0.0 0:00.00 0:00.00 - 518 0.0 0:00.00 0:00.00 - 519 0.0 0:00.00 0:00.00 - 520 0.0 0:00.00 0:00.00 - 521 0.0 0:00.00 0:00.00 - 522 0.0 0:00.00 0:00.00 - 523 0.0 0:00.00 0:00.00 - 524 0.0 0:00.00 0:00.00 - 525 0.0 0:00.00 0:00.00 - 526 0.0 0:00.00 0:00.00 - 527 0.0 0:00.00 0:00.00 - 528 0.0 0:00.00 0:00.00 - 529 0.0 0:00.00 0:00.00 - 530 0.0 0:00.00 0:00.00 - 531 0.0 0:00.00 0:00.00 - 532 0.0 0:00.00 0:00.00 - 533 0.0 0:00.00 0:00.00 - 534 0.0 0:00.00 0:00.00 - 535 0.0 0:00.00 0:00.00 - 536 0.0 0:00.00 0:00.00 - 537 0.0 0:00.00 0:00.00 - 538 0.0 0:00.00 0:00.00 - 539 0.0 0:00.00 0:00.00 - 540 0.0 0:00.00 0:00.00 - 541 0.0 0:00.00 0:00.00 - 542 0.0 0:00.00 0:00.00 - 543 0.0 0:00.00 0:00.00 - 544 0.0 0:00.00 0:00.00 - 545 0.0 0:00.00 0:00.00 - 546 0.0 0:00.00 0:00.00 - 547 0.0 0:00.00 0:00.00 - 548 0.0 0:00.00 0:00.00 - 549 0.0 0:00.00 0:00.00 - 550 0.0 0:00.00 0:00.00 - 551 0.0 0:00.00 0:00.00 - 552 0.0 0:00.00 0:00.00 - 553 0.0 0:00.00 0:00.00 - 554 0.0 0:00.00 0:00.00 - 555 0.0 0:00.00 0:00.00 - 556 0.0 0:00.00 0:00.00 - 557 0.0 0:00.00 0:00.00 - 558 0.0 0:00.00 0:00.00 - 559 0.0 0:00.00 0:00.00 - 560 0.0 0:00.00 0:00.00 - 561 0.0 0:00.00 0:00.00 - 562 0.0 0:00.00 0:00.00 - 563 0.0 0:00.00 0:00.00 - 564 0.0 0:00.00 0:00.00 - 565 0.0 0:00.00 0:00.00 - 566 0.0 0:00.00 0:00.00 - 567 0.0 0:00.00 0:00.00 - 568 0.0 0:00.00 0:00.00 - 569 0.0 0:00.00 0:00.00 - 570 0.0 0:00.00 0:00.00 - 571 0.0 0:00.00 0:00.00 - 572 0.0 0:00.00 0:00.00 - 573 0.0 0:00.00 0:00.00 - 574 0.0 0:00.00 0:00.00 - 575 0.0 0:00.00 0:00.00 - 576 0.0 0:00.00 0:00.00 - 577 0.0 0:00.00 0:00.00 - 578 0.0 0:00.00 0:00.00 - 579 0.0 0:00.00 0:00.00 - 580 0.0 0:00.00 0:00.00 - 581 0.0 0:00.00 0:00.00 - 582 0.0 0:00.00 0:00.00 - 583 0.0 0:00.00 0:00.00 - 584 0.0 0:00.00 0:00.00 - 585 0.0 0:00.00 0:00.00 - 586 0.0 0:00.00 0:00.00 - 587 0.0 0:00.00 0:00.00 - 588 0.0 0:00.00 0:00.00 - 589 0.0 0:00.00 0:00.00 - 590 0.0 0:00.00 0:00.00 - 591 0.0 0:00.00 0:00.00 - 592 0.0 0:00.00 0:00.00 - 593 0.0 0:00.00 0:00.00 - 594 0.0 0:00.00 0:00.00 - 595 0.0 0:00.00 0:00.00 - 596 0.0 0:00.00 0:00.00 - 597 0.0 0:00.00 0:00.00 - 598 0.0 0:00.00 0:00.00 - 599 0.0 0:00.00 0:00.00 - 600 0.0 0:00.00 0:00.00 - 601 0.0 0:00.00 0:00.00 - 602 0.0 0:00.00 0:00.00 - 603 0.0 0:00.00 0:00.00 - 604 0.0 0:00.00 0:00.00 - 605 0.0 0:00.00 0:00.00 - 606 0.0 0:00.00 0:00.00 - 607 0.0 0:00.00 0:00.00 - 608 0.0 0:00.00 0:00.00 - 609 0.0 0:00.00 0:00.00 - 610 0.0 0:00.00 0:00.00 - 611 0.0 0:00.00 0:00.00 - 612 0.0 0:00.00 0:00.00 - 613 0.0 0:00.00 0:00.00 - 614 0.0 0:00.00 0:00.00 - 615 0.0 0:00.00 0:00.00 - 616 0.0 0:00.00 0:00.00 - 617 0.0 0:00.00 0:00.00 - 618 0.0 0:00.00 0:00.00 - 619 0.0 0:00.00 0:00.00 - 620 0.0 0:00.00 0:00.00 - 621 0.0 0:00.00 0:00.00 - 622 0.0 0:00.00 0:00.00 - 623 0.0 0:00.00 0:00.00 - 624 0.0 0:00.00 0:00.00 - 625 0.0 0:00.00 0:00.00 - 626 0.0 0:00.00 0:00.00 - 627 0.0 0:00.00 0:00.00 - 628 0.0 0:00.00 0:00.00 - 629 0.0 0:00.00 0:00.00 - 630 0.0 0:00.00 0:00.00 - 631 100.3 8:11.86 17:35.07 - 175 0 3 1 1 6 130M 1.08M 0.0 0:03.06 0:33.84 /hurd/term /dev/ptyp0 pty-master /dev/ttyp0 - 0 0.0 0:00.80 0:07.55 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.56 0:05.97 - 3 0.0 0:00.50 0:06.99 - 4 0.0 0:00.56 0:06.99 - 5 0.0 0:00.62 0:06.32 - 176 1000 173 176 176 2 148M 2.19M 0.0 0:00.08 0:00.54 -bash - 0 0.0 0:00.08 0:00.47 - 1 0.0 0:00.00 0:00.07 - 284 1000 1 284 284 2 20.5M 700K 0.0 0:00.00 0:00.00 ssh-agent - 0 0.0 0:00.00 0:00.00 - 1 0.0 0:00.00 0:00.00 - 302 1000 176 302 176 3 148M 1.37M 0.0 0:00.03 0:00.14 screen -S S_main - 0 0.0 0:00.02 0:00.07 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.01 0:00.06 - 304 1000 302 304 304 3 148M 2.45M 0.0 0:02.86 0:13.03 SCREEN -S S_main - 0 0.0 0:02.86 0:12.97 - 1 0.0 0:00.00 0:00.03 - 2 0.0 0:00.00 0:00.02 - 305 1000 3 1 1 5 130M 960K 0.0 0:01.57 0:15.62 /hurd/fifo - 0 0.0 0:00.31 0:04.04 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.31 0:03.95 - 3 0.0 0:00.45 0:03.78 - 4 0.0 0:00.49 0:03.84 - 306 0 3 1 1 5 130M 1.02M 0.0 0:01.42 0:16.72 /hurd/term /dev/ptyp1 pty-master /dev/ttyp1 - 0 0.0 0:00.43 0:06.13 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.40 0:04.77 - 3 0.0 0:00.00 0:00.14 - 4 0.0 0:00.59 0:05.67 - 309 1000 304 309 309 2 148M 2.12M 0.0 0:00.02 0:00.09 /bin/bash - 0 0.0 0:00.02 0:00.09 - 1 0.0 0:00.00 0:00.00 - 319 1000 309 319 309 2 153M 7.29M 0.0 0:00.33 0:00.74 emacs - 0 0.0 0:00.33 0:00.74 - 1 0.0 0:00.00 0:00.00 - 320 0 3 1 1 6 130M 1.48M 0.0 0:03.25 0:38.79 /hurd/term /dev/ptyp2 pty-master /dev/ttyp2 - 0 0.0 0:00.60 0:07.07 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.69 0:08.43 - 3 0.0 0:00.78 0:07.78 - 4 0.0 0:00.55 0:07.98 - 5 0.0 0:00.60 0:07.52 - 323 1000 304 323 323 2 148M 2.19M 0.0 0:00.12 0:00.60 /bin/bash - 0 0.0 0:00.12 0:00.54 - 1 0.0 0:00.00 0:00.06 - 411 0 3 1 1 5 130M 1.02M 0.0 0:01.17 0:16.40 /hurd/term /dev/ptyp3 pty-master /dev/ttyp3 - 0 0.0 0:00.42 0:03.74 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.15 0:02.70 - 3 0.0 0:00.24 0:05.48 - 4 0.0 0:00.33 0:04.45 - 414 1000 304 414 414 2 148M 2.13M 0.0 0:00.05 0:00.23 /bin/bash - 0 0.0 0:00.04 0:00.21 - 1 0.0 0:00.00 0:00.02 - 425 0 3 1 1 3 130M 872K 0.0 0:00.02 0:00.05 /hurd/proxy-defpager - 0 0.0 0:00.02 0:00.04 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.00 0:00.01 - 3087 0 3 1 1 5 130M 1.02M 0.0 0:00.23 0:01.39 /hurd/term /dev/ptyp4 pty-master /dev/ttyp4 - 0 0.0 0:00.05 0:00.39 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.07 0:00.43 - 3 0.0 0:00.07 0:00.31 - 4 0.0 0:00.04 0:00.26 - 3648 0 3 1 1 3 130M 876K 0.0 0:00.00 0:00.05 /hurd/crash --kill - 0 0.0 0:00.00 0:00.05 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.00 0:00.00 - 5512 0 3 1 1 5 130M 1.01M 0.0 0:00.05 0:00.70 /hurd/term /dev/ptyp5 pty-master /dev/ttyp5 - 0 0.0 0:00.00 0:00.26 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.03 0:00.16 - 3 0.0 0:00.02 0:00.14 - 4 0.0 0:00.00 0:00.14 - 10286 1000 323 10286 323 2 135M 1.28M 0.0 0:00.06 0:00.20 make - 0 0.0 0:00.06 0:00.20 - 1 0.0 0:00.00 0:00.00 - 10287 1000 323 10286 323 2 147M 884K 0.0 0:00.00 0:00.33 tee standard output L_ LC_PAPER=en_US.utf8 LC_ADDRESS=en_US.utf8 SSH_AGENT_PID=284 LC_MONETARY= - [165CM=en_US.utf8 SP_REPLACE_LINKS=n SHELL=/bin/bash TERM=screen SP_STOP_AFTER=build HISTSIZE=10000 SSH_CLIENT=192.168.10.60 55972 22 LC_NUMERIC=en_US.utf8 OLDPWD=/home/tsch - [165CMhwinge SSH_TTY=/dev/ttyp0 USER=tschwinge HISTFILESIZE=10000 LD_LIBRARY_PATH= LC_TELEPHONE=en_US.utf8 SP_COMPAT=n LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01; - [165CM;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=0 - [165CM01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31: - [165CM:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35 - [165CM5:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=0 - [165CM01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm - [165CMm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.an - [165CMnx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*. - [165CM.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36: SSH_AUTH_SOCK=/home/tschwinge/.ssh/auth_sock.grubber.bddebian.com TERMCAP=SC|screen|VT 100/ANSI X3.64 virtual terminal - [165CMl:\^K^J:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:bs:bt=\E[Z:\^K^J:cd=\E[J:ce=\E[K:cl=\E[H\E[J:cm=\E[%i%d;%dH:ct=\E[3g:\^K^J:do=^J:nd=\E[C:pt:rc=\E8:rs=\Ec:sc=\E7:st=\EH - [165CMH:up=\EM:\^K^J:le=^H:bl=^G:cr=^M:it#8:ho=\E[H:nw=\EE:ta=^I:is=\E)0:\^K^J:li#50:co#166:am:xn:xv:LP:sr=\EM:al=\E[L:AL=\E[%dL:\^K^J:cs=\E[%i%d;%dr:dl=\E[M:DL=\E[%dM:dc=\E - [165CME[P:DC=\E[%dP:\^K^J:im=\E[4h:ei=\E[4l:mi:IC=\E[%d@:ks=\E[?1h\E=:\^K^J:ke=\E[?1l\E>:vi=\E[?25l:ve=\E[34h\E[?25h:vs=\E[34l:\^K^J:ti=\E[?1049h:te=\E[?1049l:us=\E[4m:ue=\E - [165CME[24m:so=\E[3m:\^K^J:se=\E[23m:mb=\E[5m:md=\E[1m:mr=\E[7m:me=\E[m:ms:\^K^J:Co#8:pa#64:AF=\E[3%dm:AB=\E[4%dm:op=\E[39;49m:AX:\^K^J:vb=\Eg:G0:as=\E(0:ae=\E(B:\^K^J:ac=\1 - [165CM140\140aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~..--++,,hhII00:\^K^J:po=\E[5i:pf=\E[4i:k0=\E[10~:k1=\EOP:k2=\EOQ:k3=\EOR:\^K^J:k4=\EOS:k5=\E[15~:k6=\E[17~:k7=\E - [165CME[18~:k8=\E[19~:\^K^J:k9=\E[20~:k;=\E[21~:F1=\E[23~:F2=\E[24~:F3=\E[1;2P:\^K^J:F4=\E[1;2Q:F5=\E[1;2R:F6=\E[1;2S:F7=\E[15;2~:\^K^J:F8=\E[17;2~:F9=\E[18;2~:FA=\E[19;2~:k - [165CMkb=\177:K2=\EOE:\^K^J:kB=\E[Z:kF=\E[1;2B:kR=\E[1;2A:*4=\E[3;2~:*7=\E[1;2F:\^K^J:#2=\E[1;2H:#3=\E[2;2~:#4=\E[1;2D:%c=\E[6;2~:%e=\E[5;2~:\^K^J:%i=\E[1;2C:kh=\E[1~:@1=\E[ - [165CM[1~:kH=\E[4~:@7=\E[4~:\^K^J:kN=\E[6~:kP=\E[5~:kI=\E[2~:kD=\E[3~:ku=\EOA:kd=\EOB:\^K^J:kr=\EOC:kl=\EOD:km: have_bash_profile=y SPF_SOURCE_DEBUG=y PATH=/home/tschwinge/c - [165CMcommand:/home/tschwinge/shared/command:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games MAIL=/var/mail/tschwinge LC_MESSAGES=en_US.utf8 SP_TARDIR=/ - [165CM/home/tschwinge/tmp/source/package STY=304.S_main LC_COLLATE=C LC_IDENTIFICATION=en_US.utf8 SP_FOREIGN_DIR=/home/tschwinge/shared.old/package/host/schwinge.homeip.net/ - [165CM/sp-foreign-snippets/snippets PWD=/home/tschwinge/tmp/emacs/trunk.build _LD_LIBRARY_PATH= EDITOR=emacsclient LANG=en_US.utf8 TZ=Europe/Berlin LC_MEASUREMENT=en_US.utf - [165CMf8 KRB5CCNAME=/tmp/krb5cc.tschwinge HISTCONTROL=ignoreboth HOME=/home/tschwinge SHLVL=2 SPF_COMPAT=n LOGNAME=tschwinge LESS=-M -R CVS_RSH=ssh WINDOW=1 SSH_CONNECTION=1 - [165CM192.168.10.60 55972 192.168.10.63 22 LC_CTYPE=en_US.utf8 LESSOPEN=| /usr/bin/lesspipe %s EMAIL=thomas@schwinge.name ALTERNATE_EDITOR=joe LC_TIME=en_US.utf8 LESSCLOSE=/ - [165CM/usr/bin/lesspipe %s %s SPF_SOURCE_DATA_DIR=/home/tschwinge/shared.old/source/package/misc/spf LC_NAME=en_US.utf8 _=/usr/bin/tee - 0 0.0 0:00.00 0:00.33 - 1 0.0 0:00.00 0:00.00 - 10377 1000 10286 10286 323 2 146M 828K 0.0 0:00.00 0:00.00 /bin/sh -c boot=bootstrap-emacs; \^Kif [ ! -x "src/$boot" ]; then - [165CM \^K cd src; make all \^K CC='gcc' CFLAGS='-g' CPPFLAGS='-DXASSERTS=1' \^K LDFLA - [165CMAGS='-Wl,-znocombreloc ' MAKE='make' BOOTSTRAPEMACS="$boot"; \^Kfi; - 0 0.0 0:00.00 0:00.00 - 1 0.0 0:00.00 0:00.00 - 10378 1000 10377 10286 323 2 135M 1.65M 0.0 0:00.71 0:02.12 make all CC=gcc CFLAGS=-g CPPFLAGS=-DXASSERTS=1 LDFLAGS=-Wl,-znocombreloc MAKE=make BOOTSTRAPE - [165CMEMACS=bootstrap-emacs - 0 0.0 0:00.71 0:01.92 - 1 0.0 0:00.00 0:00.19 - 10770 1000 10378 10286 323 2 146M 852K 0.0 0:00.00 0:00.03 /bin/sh -c if test "no" = "yes"; then \^K ln -f temacs bootstrap-emacs; \^Kelse \^K `/bin/pwd - [165CMd`/temacs --batch --load loadup bootstrap || exit 1; \^K mv -f emacs bootstrap-emacs; \^Kfi - 0 0.0 0:00.00 0:00.03 - 1 0.0 0:00.00 0:00.00 - 10772 1000 10770 10286 323 3 180M 38.8M 0.0 1:16.35 0:05.27 /media/data/home/tschwinge/tmp/emacs/trunk.build/src/temacs --batch --load loadup bootstrap - 0 0.0 1:16.35 0:05.27 - 1 0.0 0:00.00 0:00.00 - 2 0.0 0:00.00 0:00.00 - 10778 1000 304 304 304 2 148M 396K 0.0 0:00.00 0:00.00 SCREEN -S S_main - 0 0.0 0:00.00 0:00.00 - 1 0.0 0:00.00 0:00.00 - 10784 - 160 10784 160 2 146M 672K 0.0 0:00.00 0:00.01 syncfs -s - 0 0.0 0:00.00 0:00.01 - 1 0.0 0:00.00 0:00.00 - 10785 - 160 10785 160 2 146M 672K 0.0 0:00.00 0:00.02 syncfs -s -c /media/data/ - 0 0.0 0:00.00 0:00.02 - 1 0.0 0:00.00 0:00.00 - 10787 0 160 10787 160 2 146M 876K 0.0 0:00.00 0:00.06 ps -Af - 0 0.0 0:00.00 0:00.06 - 1 0.0 0:00.00 0:00.00 - 10795 8 131 6 6 2 147M 1.38M 0.1 0:00.02 0:00.04 /usr/lib/nullmailer/qmqp -d -s mail.schwinge.homeip.net - 0 0.1 0:00.02 0:00.04 - 1 0.0 0:00.00 0:00.00 - 10796 0 160 10796 160 2 146M 1.23M 0.0 0:00.00 0:00.08 ps -F hurd-long -T -M -w -A - 0 0.0 0:00.00 0:00.03 - 1 0.0 0:00.00 0:00.00 - - [4]+ Done ps -F hurd-long -T -M -w -A - login> - -TH# 631 of PID 174 (which is indeed ext2fs for /media/data) looks very -suspicious, likely together in combination with TH# 1 of PID 2 (GNU Mach), so -likely some IPC ping-pong? - - PID TH# UID PPID PGrp Sess TH Vmem RSS %CPU User System Args - 0 0 1 1 1 16 132M 1M 0.0 0:04.84 0:54.84 /hurd/proc - [...] - 2 - 1 1 1 7 418M 19.5M 0.0 0:00.00 0:12.16 root=device:hd0 - 0 0.0 0:00.00 0:00.00 - 1 92.6 0:00.00 46:33.66 - 2 0.0 0:00.00 0:12.07 - 3 0.0 0:00.00 0:00.05 - 4 0.0 0:00.00 0:00.02 - 5 0.0 0:00.00 0:00.00 - 6 0.0 0:00.00 0:00.01 - [...] - 174 0 3 1 1 632 2.99G 27.6M 100.3 16:43.18 52:54.41 /hurd/ext2fs /dev/hd2 - 0 0.0 0:00.01 0:00.03 - 1 0.0 0:00.00 0:00.00 - 2 0.0 1:34.24 6:26.66 - 3 0.0 0:00.04 0:00.31 - [...] - 630 0.0 0:00.00 0:00.00 - 631 100.3 8:11.86 17:35.07 - [...] - -Attaching GDB hangs. Should have used noninvasive mode... - -Having a look again after an hour or two, GNU Mach's thread 1's (system) time -count has gone up to nearly 120 minutes, and ext2fs' thread 631's is up to 12 -minutes user and 26 minutes system time. - -I was able to get another root shell via plain `ssh root@grubber`, and I'm able -to attach GDB in noninvasive mode. Hopefully the first unsuccessful (but still -running) GDB didn't cause any interference. - -Due to differences in [[thread_numbering_of_ps_and_gdb]], GDB's thread 632 -(which is the last one anyways) should be the offending one. GDB's thread 631 -and earlier ones (manually checked down to 600) are sitting in `mach_msg_trap`. - - (gdb) thread apply 632 bt - - Thread 632 (Thread 174.632): - #0 0x010e408c in syscall_vm_allocate () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/syscall_vm_allocate.S:2 - #1 0x010e423a in __vm_allocate (target_task=1, address=0xbfffbde0, size=65536, anywhere=0) - at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/vm_allocate.c:54 - #2 0x010b023a in alloc_stack (p=0x83774a8) at /home/sthibaul-guest/hurd-debian/./libthreads/stack.c:397 - #3 0x010ae9b3 in cproc_create () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:724 - #4 0x010afe5a in cthread_fork (func=0x133ff42, arg=0x0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:341 - #5 0x010b505d in internal_demuxer (inp=0xbfffdf20, outheadp=0xbfffbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:72 - #6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109 - #7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 - #8 0x010b0058 in cthread_body (self=0x8376c50) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 - #9 0x00000000 in ?? () - - (gdb) thread apply 632 bt full - - Thread 632 (Thread 174.632): - #0 0x010e408c in syscall_vm_allocate () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/syscall_vm_allocate.S:2 - No locals. - #1 0x010e423a in __vm_allocate (target_task=1, address=0xbfffbde0, size=65536, anywhere=0) - at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/vm_allocate.c:54 - err = <value optimized out> - #2 0x010b023a in alloc_stack (p=0x83774a8) at /home/sthibaul-guest/hurd-debian/./libthreads/stack.c:397 - base = 321454080 - #3 0x010ae9b3 in cproc_create () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:724 - child = 0x83774a8 - n = <value optimized out> - #4 0x010afe5a in cthread_fork (func=0x133ff42, arg=0x0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:341 - t = 0x8377430 - #5 0x010b505d in internal_demuxer (inp=0xbfffdf20, outheadp=0xbfffbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:72 - status = <value optimized out> - pi = 0x0 - link = {thread = 2050, next = 0x0, prevp = 0x2000, notifies = 0x12, interrupted_next = 0x0} - __PRETTY_FUNCTION__ = "internal_demuxer" - lock = -1073758644 - nreqthreads = -1073750240 - totalthreads = 137852072 - bucket = 0x10b1c64 - demuxer = 0x10b01eb <alloc_stack+11> - #6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109 - request = 0xbfffdf20 - reply = 0xbfffbf10 - mr = 3 - __PRETTY_FUNCTION__ = "__mach_msg_server_timeout" - #7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 - timeout = 0 - err = <value optimized out> - hook = 0 - global_timeout = 0 - thread_timeout = 0 - bucket = 0x805f6c0 - lock = 0 - totalthreads = 497 - nreqthreads = 1 - #8 0x010b0058 in cthread_body (self=0x8376c50) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 - t = 0x8376bd8 - #9 0x00000000 in ?? () - No symbol table info available. - -May this simply be an out-of-memory situation where Mach won't / can't satisfy -libports / libthreads demand? (Looks like the latter library is currently -creating a new thread.) If yes, should the code be prepared for that? Is it -perhaps prepared (I did not yet have a look), and re-tries again and again? -Why doesn't Mach page out some pages to make memory available? +# 2024-01-14 -This is stock GNU Mach from Git, no patches, configured for Xen domU usage. +Emacs version 29.1 runs on Debian GNU/Hurd. Joshua Branson uses it in +X without issue. He use org-mode, gnus, erc, calc, markdown-mode, etc. +In fact he, edits this wiki via Debian GNU/Hurd (running on a T43) +using Emacs. He is able to make changes to the wiki, render the wiki, +look at the resulting webpage with the +[[netsurf|https://www.netsurf-browser.org/]] web browser, commit the +changes, and send a patch to `bug-hurd@gnu.org`, all while using the +Hurd. :) +Also since the Hurd ported rust, you can now use +[[treesitter|https://www.masteringemacs.org/article/how-to-get-started-tree-sitter]] +with Emacs! Joshua got +[[html-ts-mode|https://github.com/mickeynp/html-ts-mode]] working. -# IRC, freenode, #hurd, 2013-10-04 +Emacs also has a packaged eglot, which is a client for language server +protocol, into core. Joshua was able to get eglot working for C mode +with clandg, but it was a bit slow. Joshua is running Emacs on a T43, +with 1.5 GB of RAM, so perhaps his hardware is just super slow. - <pinotree> given you are an emacs user: could you please pick the build - patch from deb#725099, recompile emacs24 and test it with your daily - work? +You can easily install many Emacs packages with apt: + # apt install elpa-zenburn-theme -## IRC, freenode, #hurd, 2013-10-07 +Or you can use `use-package`. - <gnu_srs> Wow! emacs24 runs in X:-D - <gnu_srs> pinotree: I've now built and installed emacs 24.3. So far so good - ^ - <pinotree> good, keep testing and stressing diff --git a/open_issues/exec.mdwn b/open_issues/exec.mdwn deleted file mode 100644 index 05deaa7a..00000000 --- a/open_issues/exec.mdwn +++ /dev/null @@ -1,84 +0,0 @@ -[[!meta copyright="Copyright © 2010, 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_hurd]] - -[[!toc]] - - -# IRC, unknown channel, unknown date. - - <youpi> oh my, disabling gzip/bzip2 support makes apt preconfigure hang - <youpi> support in exec* I meant - - <youpi> now a funny bug: if I disable gzip/bzip2 support from exec - <youpi> trying to run a zero-byte file hangs - -Justus: This doesn't seem to be an issue anymore (2013-09-08): - - % touch empty - % chmod +x empty - % ./empty - zsh: exec format error: ./empty - % bash - $ ./empty - $ - -Also I've never encountered a problem with apt. - - -## IRC, freenode, #hurd, 2013-08-01 - - <teythoon> uh, all the non trivial exec server code has #ifdef'd BFD code - all over it and it looks like that isn't even used anymore - <teythoon> that's too bad actually, I figured out how to get the values - from BFD, not so for the other elf parser that is used instead - - -## IRC, freenode, #hurd, 2013-08-05 - - <teythoon> btw, there is a Debian bug concerning zipped executables. now - I'm not sure if I understood the problem, but gziped and bzip2ed - executables work for me - <teythoon> (not that I'm a big fan of that particular feature) - <youpi> iirc these somehow got fixed yes - <youpi> something like a previous out of bound access - <teythoon> the exec server contains lot's of code that is unused and - probably bit rot (#ifdef BFD) or otherwise ignored (#if 0) - <youpi> yes :/ - <teythoon> and there's gunzipping and bunzip2ing, which we probably don't - want anyway - <pinotree> why not? - <teythoon> we should strip all that from exec and start adding features - <teythoon> pinotree: b/c it's slow and the gain is questionable - <teythoon> it breaks mmapping the code in - <teythoon> exec/exec.c is huge (~2300 lines) and complex and it is an - essential server - <teythoon> and I wonder if the unzipping is done securely, e. g. if it's - not possible to crash exec with an maliciously compressed executable - - -## IRC, freenode, #hurd, 2013-09-12 - - <rekado> The zip code in hurd/exec/ looks really complicated; does it - really just unpack zipped files in memory (which could be replaced by - library calls) or is there something else going on? - <braunr> rekado: - http://lists.gnu.org/archive/html/bug-hurd/2013-08/msg00049.html - <rekado> braunr: interesting. Thanks. - <rekado> Does this mean that the "small hack entry" on the contributing - page to use libz and libbz2 in exec is no longer valid? - <braunr> probably - ---- - -May want to have a look at using BFD / libiberty/simpleobject. - -Justus: The BFD code has been removed from the exec server. diff --git a/open_issues/exec_memory_leaks.mdwn b/open_issues/exec_memory_leaks.mdwn deleted file mode 100644 index 1fc5a928..00000000 --- a/open_issues/exec_memory_leaks.mdwn +++ /dev/null @@ -1,121 +0,0 @@ -[[!meta copyright="Copyright © 2012, 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_hurd]] - -There are is some memory leak in [[`exec`|hurd/translator/exec]]. - -[[!toc]] - - -# IRC, freenode, #hurd, 2012-08-11 - - <braunr> the exec servers seems to leak a lot - <braunr> server* - <braunr> exec now uses 109M on darnassus - <braunr> it really leaks a lot - <pinotree> only 109mb? few months ago, exec on exodar was taking more than - 200mb after few days of uptime with builds done - <braunr> i wonder how much it takes on the buildds - - -## IRC, freenode, #hurd, 2012-08-17 - - <braunr> the exec leak is tricky - <braunr> bddebian: btw, look at the TODO file in the hurd source code - <braunr> bddebian: there is a not from thomas bushnell about that - <braunr> "*** Handle dead name notifications on execserver ports. ! - <braunr> not sure it's still a todo item, but it might be worth checking - <bddebian> braunr: diskfs_execboot_class = ports_create_class (0, 0); - This is what would need to change right? It should call some cleanup - routine in the first argument? - <bddebian> Would be ideal if it could just use deadboot() from exec. - <braunr> bddebian: possible - <braunr> bddebian: hum execboot, i'm not so sure - <bddebian> Execboot is the exec task, no? - <braunr> i don't know what execboot is - <bddebian> It's from libdiskfs - <braunr> but "diskfs_execboot_class" looks like a class of ports used at - startup only - <braunr> ah - <braunr> then it's something run in the diskfs users ? - <bddebian> yes - <braunr> the leak is in exec - <braunr> if clients misbehave, it shouldn't affect that server - <bddebian> That's a different issue, this was about the TODO thing - <braunr> ah - <braunr> i don't know - <bddebian> Me either :) - <bddebian> For the leak I'm still focusing on do-bunzip2 but I am baffled - at my results.. - <braunr> ? - <bddebian> Where my counters are zero if I always increment on different - vars but wild freaking numbers if I increment on malloc and decrement on - free - - -# 2012-11-25 - -After twelve hours worth of `fork/exec` ([[GCC]]'s `check-c` part of the -testsuite), we got: - - PID UID PPID PGrp Sess TH Vmem RSS %CPU User System Args - 4 0 3 1 1 10 392M 262M 0.0 2:18.29 2hrs /hurd/exec - -The *RSS* seems a tad high. Also the system part of CPU time consumption is -quite noticeable. In comparison: - - 0 0 1 1 1 19 131M 1.14M 0.0 3:30.25 9:17.79 /hurd/proc - 3 0 1 1 1 224 405M 12.6M 0.2 42:20.25 67min ext2fs --readonly --multiboot-command-line=root=device:hd0s6 --host-priv-port=1 --device-master-port=2 --exec-server-task=3 -T typed device:hd0s6 - 276 0 3 1 1 344 442M 28.2M 0.6 48:09.36 91min /hurd/ext2fs /dev/hd2s5 - - -# 2012-12-20 - -After running the libtool testsuite for some time: - - PID TH# UID PPID PGrp Sess TH Vmem RSS %CPU User System Args - 4 0 3 1 1 11 334M 203M 60.8 3:19.73 4hrs /hurd/exec - 0 0.0 0:20.33 27:02.47 - 1 0.0 0:31.10 32:21.13 - 2 0.0 0:25.68 27:42.33 - 3 0.0 0:00.00 0:00.00 - 4 5.1 0:34.93 34:07.59 - 5 0.0 0:19.56 28:44.15 - 6 3.4 0:18.73 28:17.89 - 7 0.0 0:20.47 34:42.51 - 8 39.5 0:15.60 28:48.57 - 9 0.0 0:04.49 10:24.12 - 10 12.8 0:08.84 19:34.45 - - -# IRC, freenode, #hurd, 2013-10-08 - - * braunr hunting the exec leak - <braunr> and i think i found it - <braunr> yes :> - <braunr> testing a bit more and committing the fix later tonight - <braunr> pinotree: i've been building glibc for 40 mins and exec is still - consuming around 1m memory - <pinotree> wow nice - <pinotree> i've been noticing exec leaking quite some time ago, then forgot - to pay more attention to that - <braunr> it's been more annoying since darnassus provides web access to - cgis - <braunr> automated tools make requests every seconds - <braunr> the leak occurred when starting a shell script or using system() - <braunr> youpi: not sure you saw it, i fixed the exec leak - - -## IRC, freenode, #hurd, 2013-10-10 - - <gg0> braunr: http://postimg.org/image/jd764wfpp/ - <braunr> exec 797M - <braunr> this should be fixed with the release of the next hurd packages diff --git a/open_issues/faccessat.mdwn b/open_issues/faccessat.mdwn deleted file mode 100644 index 911acbb6..00000000 --- a/open_issues/faccessat.mdwn +++ /dev/null @@ -1,21 +0,0 @@ -[[!meta copyright="Copyright © 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]]."]]"""]] - -[[!tag open_issue_glibc open_issue_hurd]] - -`faccessat()` fails on some cases; in particular when: - -* flags does not have `AT_EACCESS` -* dirfd is not `AT_FDCWD` -* pathname is not an absolute path - -In such case, it will return -1 setting `ENOTSUP` as errno. - -[[faccessat.c]] diff --git a/open_issues/faccessat/faccessat.c b/open_issues/faccessat/faccessat.c deleted file mode 100644 index 24b1233c..00000000 --- a/open_issues/faccessat/faccessat.c +++ /dev/null @@ -1,26 +0,0 @@ -#include <fcntl.h> -#include <unistd.h> -#include <stdio.h> -#include <errno.h> -#include <string.h> -#include <stdlib.h> - -#define TESTFN "faccessat-test-file" - -int main() -{ - int fd; - int ret; - - system("touch " TESTFN ); - fd = open(".", O_RDONLY); - printf("> open: %d\n", fd); - - errno = 0; - ret = faccessat(fd, TESTFN, R_OK, 0); - printf("> faccessat: %d, %d (%s)\n", ret, errno, strerror(errno)); - - close(fd); - - return 0; -} diff --git a/open_issues/glibc/mremap.mdwn b/open_issues/glibc/mremap.mdwn deleted file mode 100644 index c17506d7..00000000 --- a/open_issues/glibc/mremap.mdwn +++ /dev/null @@ -1,70 +0,0 @@ -[[!meta copyright="Copyright © 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]]."]]"""]] - -[[!tag open_issue_glibc]] - -The Hurd does not currently support the `mremap` function. - -For the `MREMAP_MAYMOVE` case it is easy to work around; see -`[binutils]/gold/mremap.c`, for example. - -Also see the discussion of [[glibc/mmap]]. - -[[!toc]] - - -# IRC, freenode, #hurd, 2011-01-12 - - <antrik> maybe it would be easiest actually to implement mremap()?... - <braunr> antrik: i'm nto sure - <braunr> antrik: implementing mremap could be relatively easy to do - actually - <braunr> antrik: IIRC, vm_map() supports overlapping - <antrik> braunr: yes, I think so too - <antrik> braunr: haven't checked, but I have a vague recollection that the - fundamentals are pretty much there - -[[!taglink open_issue_glibc]]: check if it is possible to implement `mremap`. -[[I|tschwinge]] remember some discussion about this, but have not yet worked on -locating it. [[Talk to me|tschwinge]] if you'd like to have a look at this. - - -# IRC, OFTC, #debian-hurd, 2012-06-19 - - <bdefreese> OK, how the heck do you get an undefined reference to mremap? - <youpi> simply because we don't have it - <pinotree> mremap exists only on linux - <bdefreese> It's in sys/mman.h - <pinotree> on linux? - <bdefreese> No, on GNU/Hurd - <bdefreese> /usr/include/i386-gnu/sys/mman.h - <youpi> that's just the common file with linux - <youpi> containing just the prototype - <youpi> that doesn't mean there's an implementation behind - <pinotree> youpi: hm no, linux has an own version - <youpi> uh - <bdefreese> Ah, aye, I didn't look at the implementation.. :( - <youpi> it's then odd that it was added to the generic sys/mman.h :) - <bdefreese> Just another stub? - <pinotree> ah, only few linux archs have own versions - <youpi> for the macro values I guess - <pinotree> http://paste.debian.net/175173/ on glibc/master - <bdefreese> Hmm, so where is MREMAP_MAYMOVE coming in from? - <youpi> rgrep on a linux box ;) - <youpi> <bits/mman.h> - <youpi> but that's again linuxish - <bdefreese> Aye but with us having that in the header it is causing some - code to be run which utilizes mremap. If that wasn't defined we wouldn't - be calling it. - <youpi> ah - <youpi> we could try to remove it indeed - <bdefreese> Should I change the code to #ifdef MREMAP_MAYMOVE & !defined - __GNU__? - <youpi> no, I said we could remove the definition of MREMAP_MAYMOVE itself diff --git a/open_issues/glibc_madvise_vs_static_linking.mdwn b/open_issues/glibc_madvise_vs_static_linking.mdwn deleted file mode 100644 index 4af41931..00000000 --- a/open_issues/glibc_madvise_vs_static_linking.mdwn +++ /dev/null @@ -1,48 +0,0 @@ -[[!meta copyright="Copyright © 2010, 2011, 2012, 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_glibc]] - -[[!sourceware_PR 4822]]. - - $ echo 'int main() {}' | gcc -o /dev/null -static -x c - - /usr/lib/gcc/i486-gnu/4.4.5/../../../libcrt.a(malloc.o): In function `_int_free': - (.text+0xdc3): warning: warning: madvise is not implemented and will always fail - -This is correct, but it does confuse GNU Autoconf, for example, which then -thinks that static linking is not supported and sets a flag accordingly, which -luckly no / not many packages use. - -*This call does not influence the semantics of the application (except in the -case of MADV_DONTNEED), but may influence its performance. The kernel is free -to ignore the advice.* (`man madvise`), so we may simply want to turn it into a -no-op in glibc, avoiding the link-time warning. - -GCC c5db973fdab3db3e13db575e5650c0bcfd3630f4 (2011-10-17) makes use of this. -As we now export the symbol (and `MADV_DONTNEED`, too), GCC will no longer -`munmap` pages, but will keep them mapped for later re-use. This may increase -memory usage. The discussion in [[!message-id -"20120720162519.734e02eb@spoyarek"]] touches related topics. - -2011-07: This is what Samuel has [done for Debian -glibc](http://anonscm.debian.org/viewvc/pkg-glibc/glibc-package/trunk/debian/patches/hurd-i386/local-madvise_warn.diff). - - -# IRC, freenode, #hurd, 2012-02-16 - - <tschwinge> youpi: With Roland's fix the situation will be that just using - gcc -static doesn't emit the stub warning, but still will do so in case - that the source code itself links in madvise. Is this acceptable for - you/Debian/...? - <youpi> packages with -Werror will still bug out - <youpi> not that I consider -Werror to be a good idea, though :) - <tschwinge> youpi: Indeed. Compiler warnings can be caused by all kinds of - things. -Werror is good for development, but not for releases. diff --git a/open_issues/gnumach_i686.mdwn b/open_issues/gnumach_i686.mdwn deleted file mode 100644 index b34df73b..00000000 --- a/open_issues/gnumach_i686.mdwn +++ /dev/null @@ -1,26 +0,0 @@ -[[!meta copyright="Copyright © 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]]."]]"""]] - -[[!tag open_issue_gnumach]] - - -# IRC, freenode, #hurd, 2012-07-05 - - <braunr> we could use a gnumach-i686 too - <pinotree> how would you compile gnumach as i686 variant btw? add - -march=.. or something like that in CFLAGS? - <braunr> yes - <braunr> at least we'll get some cmovs :) - - -## IRC, freenode, #hurd, 2012-07-07 - - <braunr> it was rejected in the past because we didn't think it would bring - real performance benefit, but it actually may diff --git a/open_issues/gnumach_vm_map_entry_forward_merging.mdwn b/open_issues/gnumach_vm_map_entry_forward_merging.mdwn index 7739f4d1..b34bd61e 100644 --- a/open_issues/gnumach_vm_map_entry_forward_merging.mdwn +++ b/open_issues/gnumach_vm_map_entry_forward_merging.mdwn @@ -10,6 +10,193 @@ License|/fdl]]."]]"""]] [[!tag open_issue_gnumach]] +Mach is not always able to merge/coalesce mappings (VM entries) that +are made next to each other, leading to potentially very large numbers +of VM entries, which may slow down the VM functionality. This is said +to particularly affect ext2fs and bash. + +The basic idea of Mach designers is that entry coalescing is only an +optimization anyway, not a hard guarantee. We can apply it in the +common simple case, and just refuse to do it in any remotely complex +cases (copies, shadows, multiply referenced objects, pageout in +progress, ...). + +Suppose you define a special test program that intentionally maps +parts of a file next to each other and watches the resulting VM map +entries, and just ran a full Hurd system and observed results. + +One can stress test ext2fs in particular to check for VM entry +merging: + + # grep NR -r /usr &> /dev/null + # vminfo 8 | wc -l + +That grep opens and reads lots of files to simulate a long-running +machine (perhaps a build server); then one can look at the number of +mappings in ext2fs afterwards. Depending on how much your /usr is +populated, you will get different numbers. An older Hurd from say +2022, the above comand would result in 5,000-20,000 entries depending +on the machine! In June 2023, GNUMach gained some forward merging +functinality, which lowered the number of mappings down to 93 entries! + +(It is a separate question of why ext2fs makes that many mappings in +the first place. There could possible by a leak in ext2fs that would +be responsible for this, but none have been found so far. Possibly +another problem is that we have an unbounded node cache in libdiskfs +and Mach caching VM objects, which also keeps the node alive.) + +These are the simple forward merging cases that GNUMach now supports: + +- Forward merging: in `vm_map_enter`, merging with the next entry, in + addition to merging with the previous entry that was already there; + +- For forward merging, a `VM_OBJECT_NULL` can be merged in front of a + non-null VM object, provided the second entry has large enough + offset into the object to 'mount' the the first entry in front of + it; + +- A VM object can always be merged with itself (provded offsets/sizes + match) -- this allows merging entries referencing non-anonymous VM + objects too, such a file mappings; + +- Operations such as `vm_protect` do "clipping", which means splitting + up VM map entries, in case the specified region lands in the middle + of an entry -- but they were never "gluing" (merging, coalescing) + entries back together if the region is later vm_protect'ed back. Now + this is done (and we try to coalesce in some other cases too). This + should particularly help with "program break" (brk) in glibc, which + vm_protect's the pages allocated for the brk back and forth all the + time. + +- As another optimization, throw away unmapped physical pages when + there are no other references to the object (provided there is no + pager). Previously the pages would remain in core until the object + was either unmapped completely, or until another mapping was to be + created in place of the unmapped one and coalescing kicked in. + +- Also shrink the size of `struct vm_page` somewhat. This was a low + hanging fruit. + +`vm_map_coalesce_entry()` is analogous to `vm_map_simplify_entry()` in +other versions of Mach, but different enough to warrant a different +name. The same "coalesce" wording was used as in +`vm_object_coalesce()`, which is appropriate given that the former is +a wrapper for the latter. + +### The following provides clarifies some inaccuracies in old IRC logs: + + any request, be it e.g. `mmap()`, or `mprotect()`, can easily split + entries + +`mmap ()` cannot split entries to my knowledge, unless we're talking about +`MAP_FIXED` and unampping parts of the existing mappings. + + my ext2fs has ~6500 entries, but I guess this is related to + mapping blocks from the filesystem, right? + +No. Neither libdiskfs nor ext2fs ever map the store contents into memory +(arguably maybe they should); they just read them with `store_read ()`, +and then dispose of the the read buffers properly. The excessive number +of VM map entries, as far as I can see, is just heap memory. + + (I'm perplexed about how the kernel can merge two memory objects if + disctinct port names exist in the tasks' name space -- that's what + `mem_obj` is, right?) + + if, say, 584 and 585 above are port names which the task expects to be + able to access and do stuff with, what will happen to them when the + memory objects are merged? + +`mem_obj` in `vminfo` output is the VM object *name* port, not the +pager port (arguably `vminfo` should name it something other than +`mem_obj`). The name port is basically useful for seeing if two VM +regions have the exact same VM object mapped, and not much +else. Previously, it was also possible, as a GNU Mach extension, to +pass the name port into `vm_map ()`, but this was dropped for security +reasons. When Mach is built with `MACH_VM_DEBUG`, a name port can also +be used to query information about a VM object. + +Mach can't merge two memory objects. Mach doesn't merge *memory objects* +at all, it only merges/coalesces *VM objects*. The difference is subtle, +but important in certain contexts like this one: a "VM object" refers to +Mach's internal representation (`struct vm_object`), and a "memory object" +refers to the memory manager's implementation. There is normally a +1-to-1 correspondence between the two, but this is not always the case: +internal VM objects start without a memory object (pager) port at all, +and only get one created if/when they're paged out. There can be +multiple VM objects referencing the same backing memory object due to +copying and shadowing. + +So what Mach could do is merge the internal VM objects, by altering +page offsets to paste pages of one of the objects after the pager of +the other. But this is not implemented yet. What Mach actually does is +it avoids creating those internal VM objects and entries in the first +place, instead extending an already existing VM object and entry to +cover the new mapping. + + but at least, if two `vm_objects` are created but reference the same + externel memory object, the vm should be able to merge them back + +That never ever happens. There can only be a single `vm_object` for a +memory object. (In a single instance of Mach, that is -- if multiple +Machs access the same memory object over network-transparent IPC, each +is going to have its own `vm_object` representing the memory object.) + +See `vm_object_enter()` function, which looks up an existing VM object for +a memory object, and creates one if it doesn't yet exist. + + ok so if I get it right, the entries shown by `vmstat` are the + `vm_object`, and the mem_obj listed is a send right to the memory + object they're referencing ? + + yes + +No. The entries shown are VM map entries (`struct vm_map_entry`). There +can be entries that reference no VM object at all (`VM_OBJECT_NULL`), or +multiple entries that reference the same VM object. In fact this is +visible in the example above, the two entries mapped at `0x1311000` and at +`0x1314000` reference the same VM object, whose name port is 586. + +`mem_obj` listed is a send right to the *name* port of the VM object, not +to the memory object. Letting a task get the memory object port would be +disastrous for security (see the "No read-only mappings" vulnerability). + + i'm not sure about the type of the integer showed (port name or simply + an index) + +It is a port name (in vminfo's IPC name space) of the VM object name +port. + + if every `vm_allocate` request implies the creation of a memory object + from the default pager + +Not immediately, no. Only if the memory has to be paged out. Otherwise +an internal VM object is created without a memory object. + + and a `vm_object` is not a capability, but just an internal kernel + structure used to record the composition of the address space + +It is a kernel structure, but it also is a capability in the same way as +a task or a thread is a capability -- it is exposed as a port. +Specifically, a `memory_object_control_t` port is directly converted to a +`struct vm_object` by MIG. This would perhaps be clearer if +`memory_object_control_t` was instead named `vm_object_t`. The VM object +name port is also converted to a VM object, but this is only used in the +`MACH_VM_DEBUG RPCs`. + + i wonder when `vm_map_enter()` gets null objects though :/ + +Whenever you do `vm_map ()` with `MACH_PORT_NULL` for the object, or on +`vm_allocate ()` which is a shortcut for the same. + + the default pager backs `vm_objects` providing zero filled memory + +If that was the case, there would not be a need for a pager, Mach could +just hand out zero-filled pages. The anonymous mappings do start out +zero-filled, that is true. The default pager gets involved when the +pages are dirtied (so they no longer zero-filled) and there's memory +shortage so the pages have to paged out. + # IRC, freenode, #hurd, 2011-07-20 diff --git a/open_issues/images/overview.svg b/open_issues/images/overview.svg index bd47da91..0098d12c 100644 --- a/open_issues/images/overview.svg +++ b/open_issues/images/overview.svg @@ -2,23 +2,70 @@ <!-- Created with Inkscape (http://www.inkscape.org/) --> <svg - xmlns:osb="http://www.openswatchbook.org/uri/2009/osb" - xmlns:dc="http://purl.org/dc/elements/1.1/" - xmlns:cc="http://creativecommons.org/ns#" - xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" - xmlns:svg="http://www.w3.org/2000/svg" - xmlns="http://www.w3.org/2000/svg" - xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" - xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" width="180.62869mm" height="150.9025mm" viewBox="0 0 180.62869 150.9025" version="1.1" id="svg8" - inkscape:version="0.92.3 (2405546, 2018-03-11)" - sodipodi:docname="overview.svg"> + inkscape:version="1.2.1 (9c6d41e410, 2022-07-14)" + sodipodi:docname="overview.svg" + xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" + xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" + xmlns="http://www.w3.org/2000/svg" + xmlns:svg="http://www.w3.org/2000/svg" + xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" + xmlns:cc="http://creativecommons.org/ns#" + xmlns:dc="http://purl.org/dc/elements/1.1/"> <defs id="defs2"> + <rect + x="153.7989" + y="512.664" + width="133.75775" + height="30.069179" + id="rect15995" /> + <rect + x="70.616629" + y="204.61496" + width="133.62723" + height="25.853795" + id="rect15064" /> + <inkscape:path-effect + effect="spiro" + id="path-effect5506" + is_visible="true" + lpeversion="1" /> + <rect + x="71.043527" + y="502.39118" + width="118.31473" + height="31.646205" + id="rect5138" /> + <rect + x="433.82533" + y="435.59431" + width="188.13058" + height="23.777902" + id="rect2106" /> + <rect + x="277.88784" + y="434.10435" + width="153.88114" + height="30.839844" + id="rect652" /> + <inkscape:perspective + sodipodi:type="inkscape:persp3d" + inkscape:vp_x="0 : 75.45125 : 1" + inkscape:vp_y="0 : 1000 : 0" + inkscape:vp_z="180.62869 : 75.45125 : 1" + inkscape:persp3d-origin="90.314345 : 50.300833 : 1" + id="perspective630" /> + <rect + x="53.75" + y="475.92355" + width="158.7221" + height="36.727121" + id="rect514" /> <inkscape:path-effect effect="bspline" id="path-effect5670" @@ -33,10 +80,14 @@ inkscape:isstock="true" style="overflow:visible" id="marker5632" - refX="0" - refY="0" - orient="auto" - inkscape:stockid="Arrow2Lend"> + refX="-4.8904819" + refY="-1.3198085" + orient="178.36419678" + inkscape:stockid="Arrow2Lend" + viewBox="0 0 12.705841 9.5264135" + markerWidth="19.705999" + markerHeight="14.774898" + preserveAspectRatio="xMidYMid"> <path transform="matrix(-1.1,0,0,-1.1,-1.1,0)" d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" @@ -122,14 +173,14 @@ inkscape:stockid="Arrow1Lend" orient="auto" refY="0" - refX="0" + refX="-5" id="marker5138" style="overflow:visible" inkscape:isstock="true"> <path id="path5136" d="M 0,0 5,-5 -12.5,0 5,5 Z" - style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1.00000003pt;stroke-opacity:1" + style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1" transform="matrix(-0.8,0,0,-0.8,-10,0)" inkscape:connector-curvature="0" /> </marker> @@ -219,19 +270,6 @@ transform="matrix(0.8,0,0,0.8,10,0)" inkscape:connector-curvature="0" /> </marker> - <linearGradient - inkscape:collect="always" - id="linearGradient4525" - osb:paint="gradient"> - <stop - style="stop-color:#000000;stop-opacity:1;" - offset="0" - id="stop4521" /> - <stop - style="stop-color:#000000;stop-opacity:0;" - offset="1" - id="stop4523" /> - </linearGradient> </defs> <sodipodi:namedview id="base" @@ -240,9 +278,9 @@ borderopacity="1.0" inkscape:pageopacity="0.0" inkscape:pageshadow="2" - inkscape:zoom="0.98994949" - inkscape:cx="319.89349" - inkscape:cy="299.72889" + inkscape:zoom="0.655" + inkscape:cx="324.42748" + inkscape:cy="277.09924" inkscape:document-units="mm" inkscape:current-layer="layer1" showgrid="false" @@ -251,11 +289,15 @@ fit-margin-right="0" fit-margin-bottom="0" inkscape:snap-global="false" - inkscape:window-width="1278" - inkscape:window-height="758" + inkscape:window-width="1276" + inkscape:window-height="746" inkscape:window-x="0" - inkscape:window-y="20" - inkscape:window-maximized="1" /> + inkscape:window-y="0" + inkscape:window-maximized="0" + inkscape:showpageshadow="2" + inkscape:pagecheckerboard="0" + inkscape:deskcolor="#d1d1d1" + showguides="true" /> <metadata id="metadata5"> <rdf:RDF> @@ -264,7 +306,7 @@ <dc:format>image/svg+xml</dc:format> <dc:type rdf:resource="http://purl.org/dc/dcmitype/StillImage" /> - <dc:title></dc:title> + <dc:title /> </cc:Work> </rdf:RDF> </metadata> @@ -274,21 +316,22 @@ id="layer1" transform="translate(-24.085951,-107.64845)"> <path - style="fill:none;fill-opacity:1;stroke:#000000;stroke-width:0.96499997;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" - d="m 33.56429,116.78091 h 163.66374 v 134.9375 H 33.56429 Z" + style="fill:none;fill-opacity:1;stroke:#000000;stroke-width:1.00919;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" + d="M 30.27983,112.3293 H 199.85767 V 254.76074 H 30.27983 Z" id="rect3713" inkscape:connector-curvature="0" /> <text xml:space="preserve" - style="font-style:normal;font-weight:normal;font-size:10.58333302px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" - x="79.31002" - y="128.01953" - id="text4539"><tspan + style="font-style:normal;font-weight:normal;font-size:10.2234px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.255585" + x="81.945656" + y="118.79103" + id="text4539" + transform="scale(0.96792078,1.0331424)"><tspan sodipodi:role="line" id="tspan4537" - x="79.31002" - y="128.01953" - style="stroke-width:0.26458332">The GNU/Hurd</tspan></text> + x="81.945656" + y="118.79103" + style="stroke-width:0.255585">The GNU/Hurd</tspan></text> <flowRoot xml:space="preserve" id="flowRoot4541" @@ -299,42 +342,44 @@ height="237.14285" x="80" y="178.91158" /></flowRegion><flowPara - id="flowPara4547"></flowPara></flowRoot> <rect + id="flowPara4547" /></flowRoot> + <rect style="fill:#86ee73;fill-opacity:1;stroke:#000000;stroke-width:0.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" id="rect4553" width="153.78763" height="42.85815" - x="38.758991" - y="178.51956" + x="38.248131" + y="172.38937" inkscape:transform-center-x="4.3782942" inkscape:transform-center-y="2.4590809" /> <rect - style="fill:#c7c5f8;fill-opacity:1;stroke:#000000;stroke-width:0.47089785;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" + style="fill:#c7c5f8;fill-opacity:1;stroke:#000000;stroke-width:0.263752;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" id="rect4555" - width="65.128036" - height="17.881008" - x="81.836281" - y="229.65338" /> + width="34.778923" + height="10.50468" + x="94.432724" + y="225.66533" /> <rect style="fill:#e7ee73;fill-opacity:1;stroke:#000000;stroke-width:0.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" id="rect4557" width="154.77304" height="15.707925" x="38.28307" - y="154.56268" /> + y="150.85857" /> <text xml:space="preserve" - style="font-style:normal;font-weight:normal;font-size:10.58333302px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" - x="91.586601" - y="242.5256" - id="text4569"><tspan + style="font-style:normal;font-weight:normal;font-size:5.98974px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.149744" + x="103.41888" + y="219.21042" + id="text4569" + transform="scale(0.93964447,1.0642323)"><tspan sodipodi:role="line" - x="91.586601" - y="242.5256" - style="stroke-width:0.26458332" - id="tspan4571">Gnumach</tspan></text> + x="103.41888" + y="219.21042" + style="stroke-width:0.149744" + id="tspan455">GNU Mach</tspan></text> <rect - y="132.08675" + y="124.67848" x="38.373459" height="16.92679" width="154.59225" @@ -345,11 +390,11 @@ id="rect4585" width="51.048477" height="12.828938" - x="51.256123" - y="188.83125" /> + x="49.736835" + y="179.42331" /> <rect - y="205.80225" - x="126.92694" + y="196.62552" + x="131.30467" height="12.828938" width="51.048477" id="rect4587" @@ -359,11 +404,11 @@ id="rect4589" width="51.048477" height="12.828938" - x="51.507275" - y="205.48126" /> + x="49.985035" + y="196.81154" /> <rect - y="188.83125" - x="126.92694" + y="179.65126" + x="130.94589" height="12.828938" width="51.048477" id="rect4591" @@ -371,36 +416,36 @@ <flowRoot xml:space="preserve" id="flowRoot4593" - style="font-style:normal;font-weight:normal;font-size:26.66666794px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none" - transform="matrix(0.26458333,0,0,0.26458333,41.332896,100.22933)"><flowRegion - id="flowRegion4595" - style="font-size:26.66666794px"><rect + style="font-style:normal;font-weight:normal;font-size:21.3333px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none" + transform="matrix(0.26458333,0,0,0.26458333,45.758165,93.384506)"><flowRegion + id="flowRegion4595"><rect id="rect4597" width="157.7106" height="30.868303" x="196.97975" - y="299.61926" - style="font-size:26.66666794px" /></flowRegion><flowPara - id="flowPara4599">Hurd Servers</flowPara></flowRoot> <text + y="299.61926" /></flowRegion><flowPara + id="flowPara4599" + style="font-size:21.3333px">Hurd Servers Servers</flowPara></flowRoot> + <text xml:space="preserve" - style="font-style:normal;font-weight:normal;font-size:7.05555534px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + style="font-style:normal;font-weight:normal;font-size:7.05556px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583" x="95.447365" - y="139.10298" + y="131.69475" id="text4603"><tspan sodipodi:role="line" id="tspan4601" x="95.447365" - y="139.10298" - style="font-size:7.05555534px;stroke-width:0.26458332">Applications</tspan></text> + y="131.69475" + style="font-size:7.05556px;stroke-width:0.264583">Applications</tspan></text> <rect style="fill:none;fill-opacity:1;stroke:#000000;stroke-width:0.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" id="rect4605" width="45.435822" height="8.9989662" x="43.772575" - y="136.02699" /> + y="128.61876" /> <rect - y="136.02699" + y="128.61876" x="142.72659" height="8.9989662" width="45.435822" @@ -408,37 +453,38 @@ style="fill:none;fill-opacity:1;stroke:#000000;stroke-width:0.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" /> <text xml:space="preserve" - style="font-style:normal;font-weight:normal;font-size:5.29166651px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" - x="56.580025" - y="141.80258" - id="text4630"><tspan + style="font-style:normal;font-weight:normal;font-size:5.29167px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583" + x="57.109192" + y="134.39435" + id="text4630" + onclick="https://ladybird.dev/"><tspan sodipodi:role="line" - id="tspan4628" - x="56.580025" - y="141.80258" - style="font-size:5.29166651px;stroke-width:0.26458332">Firefox</tspan></text> + x="57.109192" + y="134.39435" + style="font-size:5.29167px;stroke-width:0.264583" + id="tspan22690">Ladybird</tspan></text> <text xml:space="preserve" - style="font-style:normal;font-weight:normal;font-size:5.29166651px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + style="font-style:normal;font-weight:normal;font-size:5.29167px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583" x="157.0732" - y="141.80258" + y="134.39435" id="text4634"><tspan sodipodi:role="line" id="tspan4632" x="157.0732" - y="141.80258" - style="font-size:5.29166651px;stroke-width:0.26458332">Emacs</tspan></text> + y="134.39435" + style="font-size:5.29167px;stroke-width:0.264583">Emacs</tspan></text> <text xml:space="preserve" - style="font-style:normal;font-weight:normal;font-size:7.05555534px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + style="font-style:normal;font-weight:normal;font-size:7.05556px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583" x="107.11687" - y="161.30249" + y="157.59837" id="text4638"><tspan sodipodi:role="line" id="tspan4636" x="107.11687" - y="161.30249" - style="font-size:7.05555534px;stroke-width:0.26458332">glibc</tspan></text> + y="157.59837" + style="font-size:7.05556px;stroke-width:0.264583">glibc</tspan></text> <flowRoot xml:space="preserve" id="flowRoot4642" @@ -450,16 +496,17 @@ height="48.487309" x="68.690376" y="330.83231" /></flowRegion><flowPara - id="flowPara4648"></flowPara></flowRoot> <text + id="flowPara4648" /></flowRoot> + <text xml:space="preserve" - style="font-style:normal;font-weight:normal;font-size:10.58333302px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" - x="66.62764" - y="197.87538" + style="font-style:normal;font-weight:normal;font-size:10.5833px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583" + x="64.917892" + y="188.84837" id="text4652"><tspan sodipodi:role="line" - x="66.62764" - y="197.87538" - style="stroke-width:0.26458332" + x="64.917892" + y="188.84837" + style="stroke-width:0.264583" id="tspan4654">auth</tspan></text> <flowRoot xml:space="preserve" @@ -472,17 +519,18 @@ height="48.487309" x="354.69034" y="330.48755" /></flowRegion><flowPara - id="flowPara4664"></flowPara></flowRoot> <text + id="flowPara4664" /></flowRoot> + <text xml:space="preserve" - style="font-style:normal;font-weight:normal;font-size:7.05555534px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" - x="137.01315" - y="197.15428" + style="font-style:normal;font-weight:normal;font-size:7.05556px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583" + x="136.11226" + y="187.49091" id="text4668"><tspan sodipodi:role="line" id="tspan4666" - x="137.01315" - y="197.15428" - style="font-size:5.29166651px;stroke-width:0.26458332">other servers</tspan></text> + x="136.11226" + y="187.49091" + style="font-size:5.29167px;stroke-width:0.264583">other translators</tspan></text> <flowRoot xml:space="preserve" id="flowRoot4670" @@ -494,17 +542,18 @@ height="48.487309" x="69.639618" y="393.76147" /></flowRegion><flowPara - id="flowPara4676"></flowPara></flowRoot> <text + id="flowPara4676" /></flowRoot> + <text xml:space="preserve" - style="font-style:normal;font-weight:normal;font-size:8.81944466px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" - x="66.104568" - y="213.70885" + style="font-style:normal;font-weight:normal;font-size:8.81944px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583" + x="53.057289" + y="205.39496" id="text4680"><tspan sodipodi:role="line" - id="tspan4678" - x="66.104568" - y="213.70885" - style="font-size:8.81944466px;stroke-width:0.26458332">pfinet</tspan></text> + x="53.057289" + y="205.39496" + style="font-size:8.81944px;stroke-width:0.264583" + id="tspan381">pfinet/lwip</tspan></text> <flowRoot xml:space="preserve" id="flowRoot4682" @@ -516,133 +565,222 @@ height="48.487309" x="354.69034" y="394.97464" /></flowRegion><flowPara - id="flowPara4688"></flowPara></flowRoot> <text + id="flowPara4688" /></flowRoot> + <text xml:space="preserve" - style="font-style:normal;font-weight:normal;font-size:10.58333302px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" - x="136.1163" - y="215.54207" + style="font-style:normal;font-weight:normal;font-size:7.05556px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583" + x="134.82208" + y="205.39278" id="text4692"><tspan sodipodi:role="line" id="tspan4690" - x="136.1163" - y="215.54207" - style="stroke-width:0.26458332">netdde</tspan></text> + x="134.82208" + y="205.39278" + style="font-size:7.05556px;stroke-width:0.264583">netdde/rump</tspan></text> <path - style="fill:none;stroke:#000000;stroke-width:0.60000002;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#Arrow2Mend)" - d="m 102.83915,211.57594 c 20.04525,-0.26727 20.04525,-0.26727 20.04525,-0.26727" + style="fill:none;stroke:#000000;stroke-width:0.6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#Arrow2Mend)" + d="m 105.09742,203.60706 c 20.04525,-0.26727 20.04525,-0.26727 20.04525,-0.26727" id="path4694" inkscape:connector-curvature="0" /> - <path - style="fill:none;stroke:#000000;stroke-width:0.5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker5380)" - d="m 177.67465,212.11048 c 2.85115,-0.0891 5.70203,-0.17819 8.18044,1.36615 2.47841,1.54434 4.58508,4.72277 5.43147,7.6181 0.84639,2.89533 0.43264,5.50799 -1.42247,8.23997 -1.85511,2.73199 -5.15105,5.58253 -10.09581,7.63174 -4.94476,2.04922 -11.53685,3.29637 -16.34782,3.60822 -4.81097,0.31185 -7.83988,-0.31175 -10.86914,-0.93542" - id="path5088" - inkscape:connector-curvature="0" - inkscape:path-effect="#path-effect5090" - inkscape:original-d="m 177.67465,212.11048 c 2.85114,-0.0894 5.70202,-0.17845 8.55263,-0.26727 2.10652,3.17756 4.21319,6.35599 6.31939,9.53438 -0.4135,2.6125 -0.82725,5.22516 -1.24127,7.83814 -3.29644,2.85093 -6.59238,5.70148 -9.88897,8.55262 -6.59295,1.2471 -13.18504,2.49425 -19.77795,3.74178 -3.02893,-0.62393 -6.05784,-1.24753 -9.08716,-1.87089" /> <rect - style="fill:none;fill-opacity:1;stroke:#000000;stroke-width:0.45291704;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" + style="fill:none;fill-opacity:1;stroke:#000000;stroke-width:0.452917;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" id="rect5454" width="44.099472" height="5.0439944" x="-136.45003" - y="141.85284" + y="134.44461" transform="scale(-1,1)" /> <text xml:space="preserve" - style="font-style:normal;font-weight:normal;font-size:4.23333311px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" - x="97.101242" - y="145.5336" + style="font-style:normal;font-weight:normal;font-size:4.23333px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583" + x="96.042908" + y="138.12537" id="text5458"><tspan sodipodi:role="line" id="tspan5456" - x="97.101242" - y="145.5336" - style="font-size:4.23333311px;stroke-width:0.26458332">Other Applications</tspan></text> + x="96.042908" + y="138.12537" + style="font-size:4.23333px;stroke-width:0.264583">Other Applications</tspan></text> <rect style="fill:none;fill-opacity:1;stroke:#000000;stroke-width:0.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" id="rect5462" width="28.207415" height="6.7667108" x="42.982037" - y="158.83899" /> + y="155.13487" /> <rect - style="fill:none;fill-opacity:1;stroke:#000000;stroke-width:0.52210951;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" + style="fill:none;fill-opacity:1;stroke:#000000;stroke-width:0.52211;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" id="rect5466" width="30.858" height="6.7446012" x="74.375511" - y="158.85004" /> + y="155.14592" /> <rect - y="158.53973" + y="154.83562" x="125.90438" height="6.7446012" width="30.858" id="rect5468" - style="fill:none;fill-opacity:1;stroke:#000000;stroke-width:0.52210951;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" /> + style="fill:none;fill-opacity:1;stroke:#000000;stroke-width:0.52211;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" /> <rect - style="fill:none;fill-opacity:1;stroke:#000000;stroke-width:0.52640831;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" + style="fill:none;fill-opacity:1;stroke:#000000;stroke-width:0.526408;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" id="rect5470" width="31.388241" height="6.7403026" x="158.37404" - y="158.54189" /> + y="154.83777" /> <text xml:space="preserve" - style="font-style:normal;font-weight:normal;font-size:5.29166651px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + style="font-style:normal;font-weight:normal;font-size:5.29167px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583" x="48.359131" - y="163.97519" + y="160.27107" id="text5474"><tspan sodipodi:role="line" id="tspan5472" x="48.359131" - y="163.97519" - style="font-size:5.29166651px;stroke-width:0.26458332">send ()</tspan></text> + y="160.27107" + style="font-size:5.29167px;stroke-width:0.264583">send ()</tspan></text> <path - style="fill:none;stroke:#000000;stroke-width:0.5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#Arrow2Lend)" - d="m 43.772571,140.48224 c -5.34513,-0.0891 -10.69052,-0.17818 -14.076045,1.82629 -3.385524,2.00446 -4.81089,6.10239 -4.409962,9.44351 0.400928,3.34112 2.627998,5.92452 4.766255,7.52818 2.138258,1.60366 4.187306,2.22728 6.236331,2.58362 2.049024,0.35633 4.09826,0.44542 6.147073,0.5345" + style="fill:none;stroke:#000000;stroke-width:0.504548;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#Arrow2Lend)" + d="m 41.991837,133.26222 c -4.826748,-0.10046 -9.653728,-0.20092 -12.710917,2.0594 -3.057188,2.26032 -4.34432,6.88131 -3.982294,10.64885 0.362025,3.76754 2.373109,6.6807 4.303993,8.48906 1.930883,1.80837 3.78121,2.51159 5.631531,2.91342 1.850321,0.40183 3.700822,0.5023 5.550941,0.60275" id="path5480" inkscape:connector-curvature="0" inkscape:path-effect="#path-effect5482" - inkscape:original-d="m 43.772571,140.48224 c -5.345126,-0.0893 -10.690516,-0.17844 -16.036172,-0.26727 -1.425242,4.09807 -2.85061,8.196 -4.276312,12.2944 2.227684,2.58355 4.454757,5.16695 6.681738,7.75082 2.049348,0.62337 4.098398,1.24699 6.147199,1.87089 2.049163,0.0888 4.098398,0.17791 6.147199,0.26726" /> + inkscape:original-d="m 41.991837,133.26222 c -4.826741,-0.1008 -9.653722,-0.20122 -14.480943,-0.30138 -1.287018,4.62114 -2.57415,9.24213 -3.861584,13.86365 2.011637,2.91332 4.022723,5.82647 6.033725,8.74014 1.850598,0.70293 3.700925,1.40615 5.551029,2.10968 1.85043,0.10005 3.700925,0.20062 5.551027,0.30139" /> <path - style="fill:none;stroke:#000000;stroke-width:0.5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker5138)" - d="m 62.481438,165.33831 c -0.712656,3.4742 -1.425374,6.9487 -3.563581,10.33429 -2.138207,3.38558 -5.701489,6.68162 -9.220664,9.79988 -3.519176,3.11827 -6.993414,6.058 -9.577165,9.57718 -2.583751,3.51918 -4.27632,7.61698 -3.830827,10.77992 0.445493,3.16294 3.028897,5.39001 5.835351,6.32543 2.806454,0.93542 5.835533,0.57906 8.864296,0.22274" + style="fill:none;stroke:#000000;stroke-width:0.399546;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker5138)" + d="m 54.936086,163.02099 c -0.508431,3.10959 -1.0169,6.21941 -2.54235,9.24964 -1.525451,3.03024 -4.067586,5.98034 -6.578249,8.77131 -2.510663,2.79098 -4.989255,5.42216 -6.832571,8.57198 -1.843317,3.14983 -3.050836,6.81753 -2.733034,9.64846 0.317801,2.83093 2.160868,4.82426 4.163091,5.66152 2.002222,0.83727 4.163238,0.51831 6.324021,0.19939" id="path5668" inkscape:connector-curvature="0" inkscape:path-effect="#path-effect5670" - inkscape:original-d="m 62.481438,165.33831 c -0.712454,3.47424 -1.425173,6.94874 -2.138156,10.42351 -3.563644,3.29635 -7.126923,6.59239 -10.690781,9.88898 -3.474507,2.93992 -6.948743,5.87966 -10.423512,8.81989 -1.692581,4.0982 -3.385149,8.196 -5.078121,12.2944 2.584071,2.22715 5.167475,4.45422 7.750816,6.68173 3.029295,-0.35662 6.058374,-0.71298 9.087164,-1.06907" /> + inkscape:original-d="m 54.936086,163.02099 c -0.508282,3.10961 -1.016752,6.21943 -1.525412,9.32949 -2.54239,2.95039 -5.084519,5.90049 -7.627062,8.85105 -2.478798,2.63138 -4.957401,5.26255 -7.436385,7.89419 -1.20753,3.66806 -2.415048,7.33576 -3.622855,11.004 1.843538,1.99338 3.686601,3.98671 5.529619,5.98043 2.161174,-0.31919 4.322192,-0.63813 6.483003,-0.95686" /> <text xml:space="preserve" - style="font-style:normal;font-weight:normal;font-size:3.52777767px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" - x="78.036789" - y="163.15187" + style="font-style:normal;font-weight:normal;font-size:4.93889px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583" + x="82.799294" + y="159.97691" id="text5686"><tspan sodipodi:role="line" - id="tspan5684" - x="78.036789" - y="163.15187" - style="font-size:3.52777767px;stroke-width:0.26458332">other functions</tspan></text> + x="82.799294" + y="159.97691" + style="font-size:4.93889px;stroke-width:0.264583" + id="tspan15664">write ()</tspan></text> <text id="text5690" - y="163.15187" - x="128.83672" - style="font-style:normal;font-weight:normal;font-size:3.52777767px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + y="159.97691" + x="132.54083" + style="font-style:normal;font-weight:normal;font-size:4.93889px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583" xml:space="preserve"><tspan - style="font-size:3.52777767px;stroke-width:0.26458332" - y="163.15187" - x="128.83672" + style="font-size:4.93889px;stroke-width:0.264583" + y="159.97691" + x="132.54083" id="tspan5688" - sodipodi:role="line">other functions</tspan></text> + sodipodi:role="line">strlen ()</tspan></text> <text xml:space="preserve" - style="font-style:normal;font-weight:normal;font-size:3.52777767px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + style="font-style:normal;font-weight:normal;font-size:3.52778px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583" x="160.58667" - y="163.15187" + y="159.44775" id="text5694"><tspan sodipodi:role="line" id="tspan5692" x="160.58667" - y="163.15187" - style="font-size:3.52777767px;stroke-width:0.26458332">other functions</tspan></text> + y="159.44775" + style="font-size:3.52778px;stroke-width:0.264583">other functions</tspan></text> + <rect + style="fill:#000000;stroke-width:0.26863" + id="rect458" + width="169.04173" + height="1.4528459" + x="30.752951" + y="222.75043" /> + <text + xml:space="preserve" + style="font-size:3.175px;fill:#000000;stroke-width:0.264583" + x="62.755424" + y="235.7558" + id="text570"><tspan + sodipodi:role="line" + id="tspan568" + style="stroke-width:0.264583" + x="62.755424" + y="235.7558" /></text> + <text + xml:space="preserve" + transform="matrix(0.39968629,0,0,0.42519352,-66.453973,31.427863)" + id="text650" + style="font-size:12px;white-space:pre;shape-inside:url(#rect652);display:inline;fill:#000000"><tspan + x="277.88867" + y="445.02202" + id="tspan21500">userspace (root) +</tspan></text> + <rect + style="fill:#87cdde;stroke:#000000;stroke-width:0.245903;stroke-opacity:1" + id="rect827" + width="46.805042" + height="10.69946" + x="134.07603" + y="241.63672" + inkscape:highlight-color="#70ee3b" /> + <text + xml:space="preserve" + transform="matrix(0.26458333,0,0,0.26458333,24.853071,129.0762)" + id="text2104" + style="font-size:18.6667px;white-space:pre;shape-inside:url(#rect2106);display:inline;fill:#87decd;stroke:#000000;stroke-opacity:1"><tspan + x="433.82617" + y="452.57812" + id="tspan21504"><tspan + style="fill:#0b0b28" + id="tspan21502">network board</tspan></tspan></text> + <text + xml:space="preserve" + transform="matrix(0.19700851,0,0,0.20398568,49.42454,125.9867)" + id="text5136" + style="font-size:18.6667px;white-space:pre;shape-inside:url(#rect5138);display:inline;fill:#ffaacc;stroke:#000000;stroke-opacity:1"><tspan + x="71.042969" + y="519.37499" + id="tspan21508"><tspan + style="fill:#000000" + id="tspan21506">kernel space</tspan></tspan></text> + <path + style="fill:#ffffff;fill-opacity:0;stroke:#000000;stroke-width:0.366964;stroke-opacity:1;marker-end:url(#marker5632)" + d="m 183.96162,204.2343 c 6.91051,4.42661 11.58258,12.17546 12.27167,20.35319 0.69511,8.24915 -2.68264,16.74417 -8.8524,22.26375" + id="path5504" + inkscape:path-effect="#path-effect5506" + inkscape:original-d="m 183.96162,204.2343 c 4.09081,6.77337 8.18138,13.56931 12.27167,20.35319 4.0903,6.78387 -5.90134,14.84301 -8.8524,22.26375" /> + <path + style="fill:#ffffff;fill-opacity:0;stroke:#000000;stroke-width:1.16715;stroke-dasharray:9.33723, 1.16715;stroke-dashoffset:0;stroke-opacity:1" + d="M 30.784693,170.07574 H 200.39486" + id="path12753" /> + <text + xml:space="preserve" + transform="matrix(0.26458333,0,0,0.26458333,37.315126,89.65673)" + id="text15062" + style="font-size:16px;white-space:pre;shape-inside:url(#rect15064);display:inline;fill:#24221c;fill-opacity:0;stroke:#000000;stroke-width:0.377953;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"><tspan + x="70.617188" + y="219.17324" + id="tspan21512"><tspan + style="fill:#000000;fill-opacity:1" + id="tspan21510">user: bob</tspan></tspan></text> + <circle + id="path2555" + style="fill:#000000;stroke:none;stroke-width:0.264583" + cx="30.373119" + cy="238.95235" + r="0.14999999" /> + <path + style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1;stroke-dasharray:none" + d="M 30.279233,239.07937 H 200.39252" + id="path2557" /> + <text + xml:space="preserve" + transform="matrix(0.26458333,0,0,0.26458333,22.49845,107.64845)" + id="text15993" + style="font-size:18.6667px;white-space:pre;shape-inside:url(#rect15995);fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:0.377953;stroke-dasharray:none"><tspan + x="153.79883" + y="529.64843" + id="tspan21516"><tspan + style="fill:#000000" + id="tspan21514">hardware</tspan></tspan></text> </g> </svg> diff --git a/open_issues/libfshelp_in_hurdlibs.mdwn b/open_issues/libfshelp_in_hurdlibs.mdwn deleted file mode 100644 index 0700b061..00000000 --- a/open_issues/libfshelp_in_hurdlibs.mdwn +++ /dev/null @@ -1,17 +0,0 @@ -[[!meta copyright="Copyright © 2008, 2009 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="libfshelp in HURDLIBS"]] - -[[!tag open_issue_hurd]] - -[[hurd/libtrivfs]] seems to use [[hurd/libfshelp]], but doesn't have it listed -in `HURDLIBS`. Should we change that? Same for [[hurd/libnetfs]] and -[[hurd/libdiskfs]]? diff --git a/open_issues/libpthread.mdwn b/open_issues/libpthread.mdwn index c628bc7b..3da5e558 100644 --- a/open_issues/libpthread.mdwn +++ b/open_issues/libpthread.mdwn @@ -13,20 +13,7 @@ License|/fdl]]."]]"""]] [[!toc]] - -# cthreads -> pthreads - -Get rid of cthreads; switch to pthreads. -Most of the issues raised on this page has been resolved, a few remain. - - -## IRC, freenode, #hurd, 2012-04-26 - - <pinotree> youpi: just to be sure: even if libpthread is compiled inside - glibc (with proper symbols forwarding etc), it doesn't change that you - cannot use both cthreads and pthreads in the same app, right? - -[[Packaging_libpthread]]. +# Packaging_libpthread. <youpi> it's the same libpthread <youpi> symbol forwarding does not magically resolve that libpthread lacks @@ -1176,7 +1163,7 @@ Most of the issues raised on this page has been resolved, a few remain. ## IRC, freenode, #hurd, 2012-09-23 <braunr> tschwinge: i committed the last hurd pthread change, - http://git.savannah.gnu.org/cgit/hurd/hurd.git/log/?h=master-pthreads + https://git.savannah.gnu.org/cgit/hurd/hurd.git/log/?h=master-pthreads <braunr> tschwinge: please tell me if you consider it ok for merging @@ -1310,7 +1297,7 @@ Most of the issues raised on this page has been resolved, a few remain. <braunr> thhe hurd must be plagued with wrong deallocations :( <braunr> i have so many problems when trying to cleanly destroy threads -[[libpthread/t/fix_have_kernel_resources]]. +[[libpthread/fix_have_kernel_resources]]. #### IRC, freenode, #hurd, 2013-11-25 @@ -1322,7 +1309,7 @@ Most of the issues raised on this page has been resolved, a few remain. #### IRC, freenode, #hurd, 2013-11-29 -See also [[open_issues/libpthread/t/fix_have_kernel_resources]]. +See also [[open_issues/libpthread/fix_have_kernel_resources]]. <braunr> there still are some leak ports making servers spawn threads with non-elevated priorities :/ @@ -1659,13 +1646,13 @@ See also [[open_issues/libpthread/t/fix_have_kernel_resources]]. does it right <braunr> in the io_select_timeout branch <braunr> see - http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/libthreads/cancel-cond.c?h=rbraun/select_timeout + https://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/libthreads/cancel-cond.c?h=rbraun/select_timeout for example * pinotree looks <braunr> what matters is the msg_delivered member used to synchronize sleeper and waker <braunr> the waker code is in - http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/libthreads/cprocs.c?h=rbraun/select_timeout + https://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/libthreads/cprocs.c?h=rbraun/select_timeout <pinotree> never seen cthreads' code before :) <braunr> soon you shouldn't have any more reason to :p <pinotree> ah, so basically the cthread version of the pthread cleanup diff --git a/open_issues/libpthread/t/fix_have_kernel_resources.mdwn b/open_issues/libpthread/fix_have_kernel_resources.mdwn index 02b6ab05..02b6ab05 100644 --- a/open_issues/libpthread/t/fix_have_kernel_resources.mdwn +++ b/open_issues/libpthread/fix_have_kernel_resources.mdwn diff --git a/open_issues/libpthread_cancellation_points.mdwn b/open_issues/libpthread_cancellation_points.mdwn index 09127e0c..cade7779 100644 --- a/open_issues/libpthread_cancellation_points.mdwn +++ b/open_issues/libpthread_cancellation_points.mdwn @@ -40,6 +40,8 @@ pthread_setcanceltype glibc/libpthread hook in the forward structure, but we are not using it: the LIBC_CANCEL_ASYNC macros are void, and we're not using them in the mig msg call either. +Update: As of glibc 2.33, some cancellation implementation was added. The test +above seems to be working fine. # Provenance diff --git a/open_issues/multithreading.mdwn b/open_issues/multithreading.mdwn index a66202c8..4f2db8fe 100644 --- a/open_issues/multithreading.mdwn +++ b/open_issues/multithreading.mdwn @@ -19,9 +19,7 @@ Hurd servers / VFS libraries are multithreaded. They can even be said to be * well-known threading libraries - * [[hurd/libthreads]] - - * [[hurd/libpthread]] + * [[/libpthread]] ## IRC, freenode, #hurd, 2011-04-20 diff --git a/open_issues/nice_changes_priority_of_parent_shell.mdwn b/open_issues/nice_changes_priority_of_parent_shell.mdwn deleted file mode 100644 index a8a08f90..00000000 --- a/open_issues/nice_changes_priority_of_parent_shell.mdwn +++ /dev/null @@ -1,15 +0,0 @@ -[[!meta copyright="Copyright © 2010 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 open_issue_glibc]] - - * [[!debbug 44039]] - - * Also see [[nice_vs_mach_thread_priorities]]. diff --git a/open_issues/nice_vs_mach_thread_priorities.mdwn b/open_issues/nice_vs_mach_thread_priorities.mdwn deleted file mode 100644 index 1f4c6ab8..00000000 --- a/open_issues/nice_vs_mach_thread_priorities.mdwn +++ /dev/null @@ -1,429 +0,0 @@ -[[!meta copyright="Copyright © 2010, 2012, 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 open_issue_glibc]] - -This issue has been known for some time, due to coreutils' testsuite choking -when testing *nice*: [[!debbug 190581]]. - -There has been older discussion about this, too, but this is not yet captured -here. - - -# IRC, freenode, #hurd, 2010-08 - - <pochu> I'm reading Mach and POSIX documentation to understand the priorities/nice problems - <pochu> antrik said it would be better to reimplement everything instead of - fixing the current Mach interfaces, though I'm not sure about that yet - <youpi> uh, so he changed his mind? - <pochu> it seems POSIX doesn't say nice values should be -20..20, but - 0..(2*NZERO - 1) - <youpi> he said we could just change the max priority value and be done - with it :) - <pochu> so we can probably define NZERO to 16 to match the Mach range of - 0..31 - <youpi> s/said/had said previously/ - <antrik> youpi: POSIX is actually fucked up regarding the definition of - nice values - <antrik> or at least the version I checked was - <pochu> antrik: why? this says the range is [0,{NZERO}*2-1], so we can just - set NZERO to 16 AFAICS: - http://www.opengroup.org/onlinepubs/9699919799/functions/getpriority.html - <antrik> it talkes about NZERO and all; making it *look* like this could be - defined arbitrarily... but in other places, it's clear that the standard - 40 level range is always assumed - <antrik> anyways, I totally see no point in deviating from other systems in - this regard. it can only cause problems, and gives us no benefits - <cfhammar> it says NZERO should be at least 20 iirc - <youpi> agreed - <antrik> I don't remember the details; it's been a while since I looked at - this - <antrik> youpi: changing the number of levels is only part of the - issue. I'm not sure why I didn't mention it initially when we discussed - this - <antrik> youpi: I already concluded years ago that it's not possible to - implement nice levels correctly with the current Mach interfaces in a - sane fashion - <antrik> (it's probably possible, but only with a stupid hack like setting - all the thread priorities one by one) - <antrik> youpi: also, last time we discussed this, I checked how the nice - stuff works currently on Hurd; and concluded that it's so utterly broken, - that there is no point in trying to preserve *any* compatibility. I think - we can safely throw away any handling that is alread there, and do it - over from scratch in the most straightforward fashion - <pochu> antrik: I've thought about setting NZERO to 16 and doing exactly - what you've just said to be a hack (setting all the thread priorities one - by one) - <pochu> but there seems to be consensus that that's undesirable... - <pochu> indeed, POSIX says NZERO should be at least 20 - <antrik> pochu: BTW, I forgot to say: I'm not sure you appreciate the - complexity of setting the thread max priorities individually - <pochu> antrik: I don't. would it be too complex? I imagined it would be a - simple loop :) - <antrik> pochu: in order to prevent race conditions, you have to stop all - other threads before obtaining the list of threads, and continue them - after setting the priority for each - <antrik> I don't even know whether it can be done without interfering with - other thread handling... in which case it gets really really ugly - <pochu> antrik: btw I'm looking at [gnumach]/kern/thread.[ch], removing the - priority stuff as appropriate, and will change the tasks code later - <antrik> it seems to me that using a more suitable kernel interface will - not only be more elegant, but quite possibly actually easier to - implement... - <pochu> antrik: apparently it's not that hard to change the priority for - all threads in a task, see task_priority() in gnumach/kern/task.c - <pochu> it looks like the nice test failures are mostly because of the not - 1:1 mapping between nice values and Mach priorities - <marcusb> "Set priority of task; used only for newly created threads." - <marcusb> there is a reason I didn't fix nice 8 years ago - <marcusb> ah there is a change_threads option - <pochu> marcusb: I'm not sure that comment is correct. that syscall is used - by setpriority() - <marcusb> yeah - <marcusb> I didn't read further, where it explains the change_threads - options - <marcusb> I was shooting before asking questions :) - <marcusb> pochu: although there are some bad interactions if max_priorities - are set per thread - <antrik> pochu: maybe we are talking past each other. my point was not that - it's hard to do in the kernel. I was just saying that it would be painful - to do from userspace with the current kernel interface - <pochu> antrik: you could still use that interface in user space, couldn't - you? or maybe I'm misunderstanding... - <pochu> cfhammar, antrik: current patch: - http://emilio.pozuelo.org/~deb/gnumach.patch, main issue is probably what - to do with high-priority threads. are there cases where there should be a - thread with a high priority but the task's priority shouldn't be high? - e.g. what to do with kernel_thread() in [gnumach]/kern/thread.c - <pochu> i.e. if tasks have a max_priority, then threads shouldn't have a - higher priority, but then either we raise the task's max_priority if we - need a high-prio thread, or we treat them specially (e.g. new field in - struct thread), or maybe it's a non-issue because in such cases, all the - task is high-prio? - <pochu> also I wonder whether I can kill the processor set's - max_priority. It seems totally unused (I've checked gnumach, hurd and - glibc) - <pochu> (that would simplify the priority handling) - <cfhammar> pochu: btw what does your patch do? i can't remember what was - decided - <pochu> cfhammar: it moves the max_priority from the thread to the task, so - raising/lowering it has effect on all of its threads - <pochu> it also increases the number of run queues (and thus that of - priority levels) from 32 to 40 so we can have a 1:1 mapping with nice - values - <pochu> cfhammar: btw don't do a full review yet, just a quick look would - be fine for now - <neal> why not do priorities from 0 to 159 - <neal> then both ranges can be scaled - <neal> without loss of precision - <pochu> neal: there would be from Mach to nice priorities, e.g. a task with - a priority of 2 another with 3 would have the same niceness, though their - priority isn't really the same - <neal> pochu: sure - <neal> pochu: but any posix priority would map to a current mach priority - and back - <neal> sorry, that's not true - <neal> a posix priority would map to a new mach priority and bach - <neal> and a current mach priority would map to a new mach priority and - back - <neal> which is I think more desirable than changing to 40 priority levels - <pochu> neal> and a current mach priority would map to a new mach priority - and back <- why should we care about this? - <neal> to be compatible with existing mach code - <neal> why gratutiously break existing interfaces? - <pochu> they would break anyway, wouldn't them? i.e. if you do - task_set_priority(..., 20), you can't know if the caller is assuming old - or new priorities (to leave it as 20 or as 100) - <neal> you add a new interface - <neal> you should avoid changing the semantics of existing interfaces as - much as possible - <pochu> ok, and deprecate the old ones I guess - <neal> following that rule, priorities only break if someone does - task_set_priority_new(..., X) and task_get_priority () - <neal> there are other users of Mach - <neal> I'd add a configure check for the new interface - <neal> alternatively, you can check at run time - <pochu> well if you _set_priority_new(), you should _get_priority_new() :) - <neal> it's not always possible - <pochu> other users of GNU Mach? - <neal> you are assuming you have complete control of all the code - <neal> this is usually not the case - <neal> no, other users of Mach - <neal> even apple didn't gratuitously break Mach - <neal> in fact, it may make sense to see how apple handles this problem - <pochu> hmm, I hadn't thought about that - <pochu> the other thing I don't understand is: "I'd add a configure check - for the new interface". a configure check where? in Mach's configure? - that doesn't make sense to me - <neal> any users of the interface - <pochu> ok so in clients, e.g. glibc & hurd - <neal> yes. - <antrik> neal: I'm not sure we are winning anything by keeping - compatibility with other users of Mach... - <antrik> neal: we *know* that to make Hurd work really well, we have to do - major changes sooner or later. we can just as well start now IMHO - <antrik> keeping compatibility just seems like extra effort without any - benefit for us - <guillem> just OOC have all other Mach forks, preserved full compatibility? - <neal> guillem: Darwin is pretty compatible, as I understand it - <antrik> pochu: the fundamental approach of changing the task_priority - interface to serve as a max priority, and to drop the notion of max - priorities from threads, looks fine - <antrik> pochu: I'm not sure about the thread priority handling - <antrik> I don't know how thread priorities are supposed to work in chreads - and/or pthread - <antrik> I can only *guess* that they assume a two-stage scheduling - process, where the kernel first decides what process to run; and only - later which thread in a process... - <antrik> if that's indeed the case, I don't think it's even possible to - implement with the current Mach scheduler - <antrik> I guess we could work with relative thread priorities if we really - want: always have the highest-priority thread run with the task's max - priority, and lower the priorities of the other threads accordingly - <antrik> however, before engaging into this, I think you should better - check whether any of the code in Hurd or glibc actually uses thread - priorities at all. my guess is that it doesn't - <antrik> I think we could get away with stubbing out thread priority - handling alltogether for now, and just use the task priority for all - threads - <antrik> I agree BTW that it would be useful to check how Darwin handles - this - <pochu> btw do you know where to download the OS X kernel source? I found - something called xnu, but I?m not sure that's it - <antrik> pochu: yeah, that's it - <antrik> Darwin is the UNIX core of OS X, and Xnu is the actual kernel... - <pochu> hmm, so they have both a task.priority and a task.max_priority - <neal> pochu: thoughts? - <pochu> neal: they have a priority and a max_priority in the task and in - the threads, new threads inherit it from its parent task - <pochu> then they have a task_priority(task, priority, max_priority) that - can change a task's priorities, and it also changes it for all its - threads - <neal> how does the global run queue work? - <pochu> and they have 128 run queues, no idea if there's a special reason - for that number - <pochu> neal: sorry, what do you mean? - <neal> I don't understand the point of the max_priority parameter - <pochu> neal: and I don't understand the point of the (base) priority ;) - <pochu> the max_priority is just that, the maximum priority of a thread, - which can be lowered, but can't exceed the max one - <pochu> the (base) priority, I don't understand what it does, though I - haven't looked too hard. maybe it's the one a thread starts at, and must - be <= max_priority - <antrik> pochu: it's clearly documented in the manual, as well as in the - code your initial patch changes... - <antrik> or do you mean the meaning is different in Darwin?... - <pochu> I was speaking of Darwin, though maybe it's the same as you say - <antrik> I would assume it's the same. I don't think there would be any - point in having the base vs. max priority distinction at all, except to - stay in line with standard Mach... - <antrik> at least I can't see a point in the base priority semantics for - use in POSIX systems... - <pochu> right, it would make sense to always have priority == max_priority - ... - <pochu> neal: so max_priority is that maximum priority, and priority is the - one used to calculate the scheduled priority, and can be raised and - lowered by the user without giving special permissions as long as he - doesn't raise it above max_priority - <pochu> well this would allow a user to lower a process' priority, and - raise it again later, though that may not be allowed by POSIX, so then we - would want to have max_priority == priority (or get rid of one of them if - possible and backwards compatible) - <antrik> pochu: right, that's what I think too - <antrik> BTW, did I bring up handling of thread priorities? I know that I - meant to, but I don't remember whether I actually did... - <pochu> antrik: you told me it'd be ok to just get rid of them for now - <pochu> so I'm more thinking of fixing max_priority and (base) priority and - leaving thread's scheduling priority as it currently is - <pochu> s/so/though/ - <antrik> pochu: well, my fear is that keeping the thread priority handling - as ist while changing task priority handling would complicate the - changes, while giving us no real benefit... - <antrik> though looking at what Darwin did there should give you an idea - what it involves exactly... - <pochu> antrik: what would you propose, keeping sched_priority == - max_priority ? - <pochu> s/keeping/making/ - <antrik> yes, if that means what I think it does ;-) - <antrik> and keeping the priority of all threads equal to the task priority - for now - <antrik> of course this only makes sense if changing it like this is - actually simpler than extending the current handling... - <antrik> again, I can't judge this without actually knowing the code in - question. looking at Darwin should give you an idea... - <pochu> I think leaving it as is, making it work with the task's - max_priority changes would be easier - <antrik> perhaps I'm totally overestimating the amount of changes required - to do what Darwin does - <antrik> OTOH, carrying around dead code isn't exactly helping the - maintainability and efficiency of gnumach... - <antrik> so I'm a bit ambivalent on this - <antrik> should we go for minimal changes here, or use this occasion to - simplify things?... - <antrik> I guess it would be good to bring this up on the ML - <cfhammar> in the context of gsoc i'd say minimal changes - <pochu> there's also neal's point on keeping backwards compatibility as - much as possible - <neal> my point was not backwards compatibility at all costs - <antrik> I'm still not convinced this is a valid point :-) - <neal> but to not gratutiously break things - <antrik> neal: well, I never suggested breaking things just because we - can... I only suggested breaking things to make the code and interface - simpler :-) - <antrik> I do not insist on it though - <neal> at that time, we did not know how Mac did it - <antrik> I only think it would be good to get into a habit that Mach - interfaces are not sacred... - <neal> and, I also had a proposal, which I think is not difficult to - implement given the existing patch - <antrik> but as I said, I do not feel strongly about this. if people feel - more confident about a minimal change, I'm fine with that :-) - <antrik> neal: err... IIRC your proposal was only about the number of nice - levels? we are discussing the interface change necessary to implement - POSIX semantics properly - <antrik> or am I misremembering? - <pochu> antrik: he argues that with that number of nice levels, we could - keep backwards compatibility for the 0..31 levels, and for 0..39 for - POSIX compatibility - <antrik> pochu: yes, I remember that part - <neal> antrik : My suggestion was: raise the number of nice levels to 160 - and introduce a new interface which uses those. Adjust the old interface - to space by 160/32 - <antrik> neal: I think I said it before: the problem is not *only* in the - number of priority levels. the semantics are also wrong. which is why - Darwin added a max_priority for tasks - <neal> what do you mean the semantics are wrong? - <neal> I apologize if you already explained this. - <antrik> hm... I explained it at some point, but I guess you were not - present at that conversation - <neal> I got disconnected recently so I likely don't have it in backlog. - <antrik> in POSIX, any process can lower its priority; while only - privileged processes can raise it - <antrik> Mach distinguishes between "current" and "max" priority for - threads: "max" behaves like POSIX; while "current" can be raised or - lowered at will, as long as it stays below "max" - <antrik> for tasks, there is only a "current" priority - <antrik> (which applies to newly created threads, and optionally can be set - for all current threads while changing the task priority) - <antrik> glibc currently uses the existing task priorities, which leads to - *completely* broken semantics - <antrik> instead, we need something like a max task priority -- which is - exactly what Darwin added - <neal> yes - <antrik> (the "current" task priority is useless for POSIX semantics as far - as I can tell; and regarding thread priorities, I doubt we actually use - them at all?...) - <cfhammar> where does a new thread get its initial max_priority from? - <antrik> cfhammar: from the creator thread IIRC - <pochu> yes - - -## IRC, freenode, #hurd, 2010-08-12 - - <pochu> my plan is to change the number of priority levels and the - threads/tasks priority handling, then add new RPCs to play with them and - make the old ones stay compatible, then make glibc use the new RPCs - - -# IRC, freenode, #hurd, 2012-12-29 - - <braunr> and, for a reason that i can't understand, there are less - priorities than nice levels, despite the fact mach was designed to run - unix systems on top of it .. - <youpi> btw, didn't we have a plan to increase that number? - <braunr> i have no idea - <braunr> but we should :) - <youpi> I remember some discussion about it on the list - - -## IRC, freenode, #hurd, 2012-12-31 - - <youpi> braunr: btw, we *do* have fixed the nice granularity - <youpi> +#define MACH_PRIORITY_TO_NICE(prio) ((prio) - 20) - <youpi> in the debian package at least - <youpi> ah, no - <youpi> it's not applied yet - <youpi> so I have the patch under hand, just not applied :) - <braunr> but that's a simple shift - <braunr> the real problem is that there aren't as many mach priorities as - there are nice levels - <youpi> that's not really a problem - <youpi> we can raise that in the kernel - <youpi> the problem is the change from shifted to unshifted - <youpi> that brings odd nice values during the upgrade - <braunr> ok - <braunr> i hope the scheduler code isn't allergic to more priorities :) - - -## IRC, freenode, #hurd, 2013-01-02 - - <braunr> pochu: i see you were working on nice levels and scheduling code - some time ago - <braunr> pochu: anything new since then ? - <pochu> braunr: nope - <braunr> pochu: were you preparing it for the gsoc ? - <pochu> braunr: can't remember right now, either that or to fix a ftbfs in - debian - <youpi> iirc it's coreutils which wants proper nice levels - - -# IRC, OFTC, #debian-hurd, 2013-03-04 - - <Steap> Is it not possible to set the priority of a process to 1 ? - <Steap> these macros: - <Steap> #define MACH_PRIORITY_TO_NICE(prio) (2 * ((prio) - 12)) - <Steap> #define NICE_TO_MACH_PRIORITY(nice) (12 + ((nice) / 2)) - <Steap> are used in the setpriority() implementation of Hurd - <Steap> so setting a process' priority to 1 is just like setting it to 0 - <youpi> Steap: that has already been discussed to drop the *2 - <youpi> the issue is mach not supporting enough sched levels - <youpi> can be fixed, of course - <youpi> just nobody did yet - -GNU Mach commit 6a234201081156e6d5742e7eeabb68418b518fad (and commit -6fe36b76f7983ec9a2e8a70420e431d54252442e). - - -## IRC, OFTC, #debian-hurd, 2013-03-07 - - <braunr> youpi: btw, why did you increase the number of priorites to 50 ? - <youpi> for the nice levels - <braunr> and probably something more, there are only 40 nice levels - <youpi> yes, the current computation leaves some margin - <youpi> so I preferred to keep a margin too - <braunr> ok - <youpi> e.g. for the idle thread, etc. - <braunr> or interrupt threads - <youpi> yep - <braunr> i see the point, thanks - <tschwinge> Is the number of 40 specified by POSIX (or whatever) or is that - a Linuxism? - <braunr> good question - <braunr> posix is weird when it comes to such old unixisms - <braunr> there is a NZERO value, but i don't remember how it's specified - <youpi> it's at least 20 - <tschwinge> (I don't object to the change; just wondered. And if practice, - you probably wouldn't really need more than a handful. But if that - change (plus some follow-up in glibc (?) improves something while not - adding a lot of overhead, then that's entirely fine, of course.) - <braunr> "A maximum nice value of 2*{NZERO}-1 and a minimum nice value of 0 - shall be imposed by the system" - <braunr> NZERO being 20 by default - <youpi> and 20 is the minimum for NZERO too - <braunr> hm, not the default, the minimul - <braunr> minimum - <braunr> yes that's it - <braunr> ok so it's actually well specified - <tschwinge> Aha, I see (just read it, too). So before that change we - simply couldn't satisfy the POSIX requirement of (minimum) NZERO = 20, - and allowing for step-1 increments. Alright. - <youpi> yep - <youpi> thus failing in coreutils testsuite diff --git a/open_issues/nightly_builds_deb_packages.mdwn b/open_issues/nightly_builds_deb_packages.mdwn index cef16734..6c5cda41 100644 --- a/open_issues/nightly_builds_deb_packages.mdwn +++ b/open_issues/nightly_builds_deb_packages.mdwn @@ -71,7 +71,7 @@ See also [[nightly_builds]]. For d-i purposes, you'll additionally need: - $ wget http://people.debian.org/~sthibault/hurd-i386/installer/cdimage/current/initrd.gz + $ wget https://cdimage.debian.org/cdimage/ports/stable/hurd-i386/initrd.gz ..., and to the `--initrd` option prepend `'initrd.gz $(ramdisk-create)',` before the `ext2fs.static`, and refer the latter to `gunzip:device:rd0` instead diff --git a/open_issues/open_symlink.mdwn b/open_issues/open_symlink.mdwn deleted file mode 100644 index 663bfcbd..00000000 --- a/open_issues/open_symlink.mdwn +++ /dev/null @@ -1,30 +0,0 @@ -[[!meta copyright="Copyright © 2012, 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_glibc]] - - -# IRC, freenode, #hurd, 2012-01-02 - - <pinotree> hm, is it a known issue that open("somesymlink", O_RDONLY | - O_NOFOLLOW) does not fail with ELOOP? - <youpi> pinotree: iirc there is code for it, maybe not the same behavior as - on linux - - -## IRC, OFTC, #debian-hurd, 2013-05-08 - - <pinotree> the hurd issue is that O_NOFOLLOW seems broken on symlinks, and - thus open(symlink, O_NOFOLLOW) doesn't fail with ELOOP - <youpi> I don't really see why it should fail - <youpi> since NOFOLLOW says not to follow the symlink - <pinotree> yeah, but you cannot open a symlink - <youpi> ah right ok - <youpi> interesting :) diff --git a/open_issues/pci_arbiter.mdwn b/open_issues/pci_arbiter.mdwn index 7fdb4323..a6f8c893 100644 --- a/open_issues/pci_arbiter.mdwn +++ b/open_issues/pci_arbiter.mdwn @@ -25,7 +25,7 @@ sequential: gnumach, netdde, and then Xorg. The PCI Arbiter will eventually allo concurrent access to the PCI config space. The Hurd now has a PCI Arbiter, but it could use some more polishing. You can find -its TODO file [[here|http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/pci-arbiter/TODO]]. +its TODO file [[here|https://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/pci-arbiter/TODO]]. Samuel also gave a presentation explaining some of the awesome possibilities that the PCI Arbiter can provide. You can watch his fosdem talk diff --git a/open_issues/perl.mdwn b/open_issues/perl.mdwn index 62d29ac1..6e05a8c0 100644 --- a/open_issues/perl.mdwn +++ b/open_issues/perl.mdwn @@ -14,7 +14,7 @@ License|/fdl]]."]]"""]] currently leads to: *Could not perform immediate configuration on 'perl'*. Easy workaround: - # apt-get install perl perl-base -o APT::Immediate-Configure=false + # apt install perl perl-base -o APT::Immediate-Configure=false """]] diff --git a/open_issues/problematic_packages.mdwn b/open_issues/problematic_packages.mdwn index 8fe06495..22054e6e 100644 --- a/open_issues/problematic_packages.mdwn +++ b/open_issues/problematic_packages.mdwn @@ -26,11 +26,6 @@ This page lists the few packages whose build makes the Debian buildd box crash a * rsyslog -* ext2fs gets stuck - - * emacs24 - * emacs25 - * loops and eats memory * pygobject diff --git a/open_issues/pth.mdwn b/open_issues/pth.mdwn deleted file mode 100644 index 12bf5098..00000000 --- a/open_issues/pth.mdwn +++ /dev/null @@ -1,28 +0,0 @@ -[[!meta copyright="Copyright © 2008, 2009, 2010 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_porting]] - -IRC, unknown channel, unknown date. - - <azeem> seems pth still doesn't work - <bddebian> Doesn't build or doesn't work? - <azeem> both - <azeem> some configure test keep grinding the CPU, same for the test suite - <azeem> which apparently runs pth_init() and never returns - - <azeem> actually, pth fails to build right now - <azeem> pth_mctx.c:477: error: request for member '__pc' in something not a structure or union - - <azeem> I know the pth test suite fails (it locks up the machine) or used to fail, so I guess porting work for pth would be needed - <azeem> < marcusb> from reading the pth/PORTING document, porting libpth shouldn't be too hard... - - <youpi> dropped pth [from the channel's topic], as we think we know why it fails (sigaltstack is bogus) diff --git a/open_issues/pthread_atfork.mdwn b/open_issues/pthread_atfork.mdwn deleted file mode 100644 index d386e5c0..00000000 --- a/open_issues/pthread_atfork.mdwn +++ /dev/null @@ -1,111 +0,0 @@ -[[!meta copyright="Copyright © 2011, 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_glibc open_issue_libpthread]] - -`pthread_atfork` is not actually implemented, making some programs fail. Code -can probably be borrowed from `nptl/sysdeps/unix/sysv/linux/register-atfork.c`. - - -# IRC, OFTC, #debian-hurd, 2013-08-21 - - <pinotree> SRCDIR/opal/mca/memory/linux/arena.c:387: warning: warning: - pthread_atfork is not implemented and will always fail - - -# Samuel's implementation - -TODO. - - -## IRC, OFTC, #debian-hurd, 2013-10-08 - - <pinotree> youpi: if you need/want to test your pthread_atfork - implementation, you can check libposix-atfork-perl and its test suite - (whose test 004 hangs now, with eglibc -93) - <youpi> while it failed previously indeed - <youpi> we might simply need to rebuild perl against it - <youpi> (I see ifdef pthread_atfork in perl) - - -## undefined reference to `__start__hurd_atfork_prepare_hook' - -### IRC, freenode, #hurd, 2013-10-16 - - <teythoon> tschwinge: I'd love to try your cross-gnu tool, the wiki page - suggests that the list of required source packages is outdated. can you - give me some hints? - <teythoon> tschwinge: I got this error running cross-gnu: - http://paste.debian.net/58303/ - make[4]: Leaving directory `/home/teythoon/repos/hurd/cross/src/glibc/setjmp' - make subdir=string -C ../string ..=../ objdir=/home/teythoon/repos/hurd/cross/obj/glibc -f Makefile -f ../elf/rtld-Rules rtld-all rtld-modules='rtld-strchr.os rtld-strcmp.os rtld-strcpy.os rtld-strlen.os rtld-strnlen.os rtld-memchr.os rtld-memcmp.os rtld-memmove.os rtld-memset.os rtld-mempcpy.os rtld-stpcpy.os rtld-memcpy.os rtld-rawmemchr.os rtld-argz-count.os rtld-argz-extract.os rtld-stpncpy.os' - make[4]: Entering directory `/home/teythoon/repos/hurd/cross/src/glibc/string' - make[4]: Leaving directory `/home/teythoon/repos/hurd/cross/src/glibc/string' - make[4]: Entering directory `/home/teythoon/repos/hurd/cross/src/glibc/string' - make[4]: Nothing to be done for `rtld-all'. - make[4]: Leaving directory `/home/teythoon/repos/hurd/cross/src/glibc/string' - make[3]: Leaving directory `/home/teythoon/repos/hurd/cross/src/glibc/elf' - i686-pc-gnu-gcc -shared -static-libgcc -Wl,-O1 -Wl,-z,defs -Wl,-dynamic-linker=/lib/ld.so.1 -B/home/teythoon/repos/hurd/cross/obj/glibc/csu/ -Wl,--version-script=/home/teythoon/repos/hurd/cross/obj/glibc/libc.map -Wl,-soname=libc.so.0.3 -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both -nostdlib -nostartfiles -e __libc_main -L/home/teythoon/repos/hurd/cross/obj/glibc -L/home/teythoon/repos/hurd/cross/obj/glibc/math -L/home/teythoon/repos/hurd/cross/obj/glibc/elf -L/home/teythoon/repos/hurd/cross/obj/glibc/dlfcn -L/home/teythoon/repos/hurd/cross/obj/glibc/nss -L/home/teythoon/repos/hurd/cross/obj/glibc/nis -L/home/teythoon/repos/hurd/cross/obj/glibc/rt -L/home/teythoon/repos/hurd/cross/obj/glibc/resolv -L/home/teythoon/repos/hurd/cross/obj/glibc/crypt -L/home/teythoon/repos/hurd/cross/obj/glibc/mach -L/home/teythoon/repos/hurd/cross/obj/glibc/hurd -Wl,-rpath-link=/home/teythoon/repos/hurd/cross/obj/glibc:/home/teythoon/repos/hurd/cross/obj/glibc/math:/home/teythoon/repos/hurd/cross/obj/glibc/elf:/home/teythoon/repos/hurd/cross/obj/glibc/dlfcn:/home/teythoon/repos/hurd/cross/obj/glibc/nss:/home/teythoon/repos/hurd/cross/obj/glibc/nis:/home/teythoon/repos/hurd/cross/obj/glibc/rt:/home/teythoon/repos/hurd/cross/obj/glibc/resolv:/home/teythoon/repos/hurd/cross/obj/glibc/crypt:/home/teythoon/repos/hurd/cross/obj/glibc/mach:/home/teythoon/repos/hurd/cross/obj/glibc/hurd -o /home/teythoon/repos/hurd/cross/obj/glibc/libc.so -T /home/teythoon/repos/hurd/cross/obj/glibc/shlib.lds /home/teythoon/repos/hurd/cross/obj/glibc/csu/abi-note.o /home/teythoon/repos/hurd/cross/obj/glibc/elf/soinit.os /home/teythoon/repos/hurd/cross/obj/glibc/libc_pic.os /home/teythoon/repos/hurd/cross/obj/glibc/elf/sofini.os /home/teythoon/repos/hurd/cross/obj/glibc/elf/interp.os /home/teythoon/repos/hurd/cross/obj/glibc/elf/ld.so /home/teythoon/repos/hurd/cross/obj/glibc/mach/libmachuser-link.so /home/teythoon/repos/hurd/cross/obj/glibc/hurd/libhurduser-link.so -lgcc - /home/teythoon/repos/hurd/cross/obj/glibc/libc_pic.os: In function `__fork': - /home/teythoon/repos/hurd/cross/src/glibc/posix/../sysdeps/mach/hurd/fork.c:70: undefined reference to `__start__hurd_atfork_prepare_hook' - /home/teythoon/repos/hurd/cross/lib/gcc/i686-pc-gnu/4.8.1/../../../../i686-pc-gnu/bin/ld: /home/teythoon/repos/hurd/cross/obj/glibc/libc_pic.os: relocation R_386_GOTOFF against undefined hidden symbol `__start__hurd_atfork_prepare_hook' can not be used when making a shared object - /home/teythoon/repos/hurd/cross/lib/gcc/i686-pc-gnu/4.8.1/../../../../i686-pc-gnu/bin/ld: final link failed: Bad value - collect2: error: ld returned 1 exit status - make[2]: *** [/home/teythoon/repos/hurd/cross/obj/glibc/libc.so] Error 1 - make[2]: Leaving directory `/home/teythoon/repos/hurd/cross/src/glibc/elf' - make[1]: *** [elf/subdir_lib] Error 2 - make[1]: Leaving directory `/home/teythoon/repos/hurd/cross/src/glibc' - make: *** [all] Error 2 - + rm -f /home/teythoon/repos/hurd/cross/sys_root/lib/ld.so - + exit 100 - - binutils-2.23.2, - gcc-4.8.1, - everything else is from git as specified in the wiki. - - -### IRC, freenode, #hurd, 2013-10-24 - - <AliciaC> in recent glibc commits (tschwinge/Roger_Whittaker branch) there - are references to _hurd_atfork_* symbols in sysdeps/mach/hurd/fork.c, and - some _hurd_fork_* symbols, some of the _hurd_fork_* symbols seem to be - defined in Hurd's boot/frankemul.ld (mostly guessing by their names being - mentioned, I don't know linker script syntax), but those _hurd_atfork_* - symbols don't seem to be defined there, are they supposed to be defined - elsewhere or is th - <AliciaC> does anyone know where the _hurd_atfork_* group of symbols - referenced in glibc are defined (if anywhere)? - <youpi> AliciaC: it's the DEFINE_HOOK (_hurd_atfork_prepare_hook, (void)); - in glibc/sysdeps/mach/hurd/fork.c - <AliciaC> hm, is that not just a declaration? - <youpi> no, it's a definition, as its name suggests : - <AliciaC> (despite the macro name) - <youpi> :) - <AliciaC> ok - <AliciaC> I should look into it more, I could have sworn I was getting - undefined references, but maybe the symbol names used are different from - those defined, but that'd be odd as well, in the same file and all - <AliciaC> I mean, I do get undefined references, but question is if it's to - things that should have been defined or not - <youpi> what undefined references do you gaT? - <youpi> s/gaT/get - <AliciaC> I'll get back to you once I have that system up again - <AliciaC> youpi: sysdeps/mach/hurd/fork.c:70: undefined reference to - `__start__hurd_atfork_prepare_hook' - <AliciaC> fork.c:70: 'RUN_HOOK (_hurd_atfork_prepare_hook, ());' - <AliciaC> DEFINE_HOOK (_hurd_atfork_prepare_hook, (void)); is higher up in - the file - <AliciaC> though there is also this message: build/libc_pic.os: relocation - R_386_GOTOFF against undefined hidden symbol - `__start__hurd_atfork_prepare_hook' can not be used when making a shared - object - - -### [[!message-id "878uvfmwvs.fsf@kepler.schwinge.homeip.net"]] diff --git a/open_issues/rpc_stub_generator.mdwn b/open_issues/rpc_stub_generator.mdwn index d4622d67..26511d3b 100644 --- a/open_issues/rpc_stub_generator.mdwn +++ b/open_issues/rpc_stub_generator.mdwn @@ -122,7 +122,7 @@ License|/fdl]]."]]"""]] <neal> the first are a burden <neal> the latter is a pain <neal> - http://git.savannah.gnu.org/gitweb/?p=hurd/viengoos.git;a=blob;f=libviengoos/viengoos/rpc.h;h=721768358a0299637fb79f226aea6a304571da85;hb=refs/heads/viengoos-on-bare-metal + https://git.savannah.gnu.org/gitweb/?p=hurd/viengoos.git;a=blob;f=libviengoos/viengoos/rpc.h;h=721768358a0299637fb79f226aea6a304571da85;hb=refs/heads/viengoos-on-bare-metal <neal> in the same directory, you there are headers that use it <braunr> neal: cf. http://genode.org/documentation/release-notes/11.05 <braunr> tschwinge: why do you recommend an IDL ? diff --git a/open_issues/running_rump_for_slash.mdwn b/open_issues/running_rump_for_slash.mdwn new file mode 100644 index 00000000..52c97b5d --- /dev/null +++ b/open_issues/running_rump_for_slash.mdwn @@ -0,0 +1,53 @@ +[[!meta copyright="Copyright © 2019 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_hurd]] + +I have been thinking about how to get rump running for the / filesystem. + +Looking at how things go between ext2fs and exec: in grub.cfg we have +roughly: + + module ext2fs --exec-server-task='${exec-task}' '$(task-create)' '$(task-resume)' + module exec '$(exec-task=task-create)' + +i.e. the kernel is told to create two tasks, to pass a reference to +the exec task to the ext2fs task, and to let only the ext2fs task to +run. What happens then is in `diskfs_start_bootstrap`, which calls +`start_execserver`, which uses `task_set_special_port` to set the +`TASK_BOOTSTRAP_PORT` special port to a send right to ext2fs, and resumes +the exec task. I.e. basically ext2fs tells exec where it is so that exec +can start the userland with `/` available. + +I'm thinking that the same can be used for the rump translator, +something like: + + module rump --fs-server-task='${fs-task}' '$(task-create)' '$(task-resume)' + module ext2fs --exec-server-task='${exec-task}' '$(fs-task=task-create)' + module exec '$(exec-task=task-create)' + +and we'd make rump's initialization use `task_set_special_port` to set +the `TASK_BOOTSTRAP_PORT` special port of ext2fs to a send right to rump, +and resume it. When ext2fs sees that this port is set, it would use it +instead of the gnumach-provided `_hurd_device_master` port to open +devices. + +And we can nest this yet more for the pci-arbiter: + + module pci-arbiter --disk-server-task='${disk-task}' '$(task-create)' '$(task-resume)' + module rump --fs-server-task='${fs-task}' '$(disk-task=task-create)' + module ext2fs --exec-server-task='${exec-task}' '$(fs-task=task-create)' + module exec '$(exec-task=task-create)' + +and we'd make `pci-arbiter`'s initialization use `task_set_special_port` +to set the `TASK_BOOTSTRAP_PORT` special port of rump to a send right to +pci-arbiter and resume it. When `libpciaccess` sees that this port is set, +it would use it instead of looking up `/server/bus/pci`. diff --git a/open_issues/sa_siginfo_sa_sigaction.mdwn b/open_issues/sa_siginfo_sa_sigaction.mdwn deleted file mode 100644 index 4e1fa849..00000000 --- a/open_issues/sa_siginfo_sa_sigaction.mdwn +++ /dev/null @@ -1,96 +0,0 @@ -[[!meta copyright="Copyright © 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="SA_SIGINFO, SA_SIGACTION"]] - -[[!tag open_issue_glibc]] - -Note: SA_SIGINFO has now been implemented by Jérémie Koenig. It will be -uploaded in Debian eglibc 2.13-19. - -IRC, #hurd, August / September 2010: - - <giselher> Hy, I came across SA_SIGINFO in cherokee, I have the void sighandler(int num) prototype but how do I add the sa_handler field? - <pinotree> if SA_SIGACTION is not defined, then you use sa_handler instead of sa_sigaction, and not add SA_SIGINFO in the sa_flags - <giselher> SA_SIGINFO is not defined - <pinotree> s/SA_SIGACTION/SA_SIGINFO/ above, yes - <giselher> K - <giselher> I am not sure if I fully understand this, there is the line "act.sa_flags = SA_SIGINFO" and how do I have to change that >_> - <pinotree> can you paste the source in a pastebin? - <giselher> k - <giselher> http://archhurd.pastebin.com/N8BCnG6g at line 790 - <pinotree> something along the lines of http://www.archhurd.pastebin.com/tdpcFD5G - <pinotree> note that in the handler the siginfo_t parameter is used, which cannot be done if SA_SIGINFO is not defined - <pinotree> (that code still won't compile, yet) - <giselher> btw: is there a reason why SA_SIGINFO is not implemented? - <giselher> the guildlines only say "It's not implemented" - <azeem> 09:43 < azeem> signal stuff is tricky :-/ - <azeem> basically it was pending on a complete rewrite by Roland, which never occured - <youpi> I have an almost complete implementation, just not finished yet - <youpi> (only the siginfo part) - <azeem> nobody really groked that code for years until youpi showed up, but he added partial support AFAIK, not having much time on his hand - <azeem> ah, he's here - <azeem> :) - <giselher> oh, should I just wait ? - <youpi> no - <giselher> k - <youpi> there are OSes which don't have SA_SIGINFO - <youpi> just cope with them: use sa_handler instead of sa_sigaction, and don't set SA_SIGINFO - <youpi> (i.e. replace with 0 in your example) - <giselher> ok - <youpi> when SA_SIGINFO becomes available, it'll just be used - -IRC, freenode, #hurd, 2011-08-20: - - < youpi> erf, tcpwrappers will need si_pid - < jkoenig> I could implement it not too far away in the future, we just - need a version of msg_sig_post() with a siginfo argument or something. - < youpi> I can also see a lot of packages using SA_SIGINFO for no reason... - < youpi> (probably copy/pasty code) - < youpi> sa.sa_flags = SA_SIGINFO; - < youpi> sa.sa_handler = parse_config; - < youpi> void parse_config(int) - < youpi> yay - < youpi> if(siginf->si_signo == SIGXCPU) - < youpi> fprintf(stderr, "Exceeded CPU usage.\n"); - < youpi> ... - < youpi> jkoenig: actually most package don't actually use the SA_SIGINFO - they request... - < youpi> jkoenig: si_pid should get us almost all actually used coverage - < youpi> I've seen only one example using si_errno - < jkoenig> ok - < youpi> oh, it's actually supported by your patch - < youpi> (errno) - < jkoenig> but I guess since implementing si_pid will require a new RPC, we - might as well plan for the rest - < youpi> jkoenig: indeed - < jkoenig> youpi, hmm I doubt it's properly filled in in all circumstances? - < youpi> ok, well, we'll see - < pinotree> jkoenig: if it can be of help, boost::unit_test queries various - fields of siginfo_t depending on the signal - < pinotree> jkoenig: also, pulseaudio uses siginfo_t for remapping faulting - memory on SIGBUS - < jkoenig> pinotree, oh ok good to know - < pinotree> *faulty - < youpi> jkoenig: well, I guess you had checked that the si_addr field is - correct in a few simple testcase :) - < jkoenig> hmm I think so, yes - < jkoenig> I ran like, "* (char *) 0x12345678;" or something IIRC - < youpi> ok - < jkoenig> I seem to remember mach generated SIGBUS instead of SIGSEGV - depending on the upper bit, or something (I can't quite remember) - < jkoenig> but when sigsegv was generated si_addr was right. - < pinotree> jkoenig: (see boost/test/impl/execution_monitor.ipp in boost - sources) - < pinotree> maybe you can try the unit tests for boost::unit_tests, if any - :) - < pinotree> (while src/pulsecore/memtrap.c in PA) - * pinotree stops doing MrObvious™ diff --git a/open_issues/select.mdwn b/open_issues/select.mdwn index caecc437..19468d90 100644 --- a/open_issues/select.mdwn +++ b/open_issues/select.mdwn @@ -1103,7 +1103,7 @@ IRC, unknown channel, unknown date: <braunr> unfortunately, my idea alone isn't enough <braunr> for those interested in the problem, i've updated the analysis in my last commit - (http://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?h=rbraun/select_timeout&id=40fe717ba9093c0c893d9ea44673e46a6f9e0c7d) + (https://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?h=rbraun/select_timeout&id=40fe717ba9093c0c893d9ea44673e46a6f9e0c7d) #### IRC, freenode, #hurd, 2012-08-01 @@ -1660,7 +1660,7 @@ IRC, unknown channel, unknown date: #### IRC, freenode, #hurd, 2012-12-17 <braunr> tschwinge: - http://git.savannah.gnu.org/cgit/hurd/glibc.git/log/?h=rbraun/select_timeout_for_one_fd + https://git.savannah.gnu.org/cgit/hurd/glibc.git/log/?h=rbraun/select_timeout_for_one_fd <braunr> gnu_srs: talking about that, can you explain : <braunr> "- The pure delay case is much faster now, making it necessary to <braunr> introduce a delay of 1 msec when the timeout parameter is set to diff --git a/open_issues/serial_console.mdwn b/open_issues/serial_console.mdwn index 827fd211..3100d60c 100644 --- a/open_issues/serial_console.mdwn +++ b/open_issues/serial_console.mdwn @@ -67,7 +67,7 @@ License|/fdl]]."]]"""]] <braunr> we definitely want it to work with 8N1 <gg0> never had problems with _virtual_ serial consoles <gg0> never = during last 2 years = since - http://git.savannah.gnu.org/gitweb/?p=hurd/gnumach.git;a=commitdiff;h=2a603e88f86bee88e013c2451eacf076fbcaed81 + https://git.savannah.gnu.org/gitweb/?p=hurd/gnumach.git;a=commitdiff;h=2a603e88f86bee88e013c2451eacf076fbcaed81 <gg0> but i don't think i was on real hardware at that time diff --git a/open_issues/serverbootv2.mdwn b/open_issues/serverbootv2.mdwn new file mode 100644 index 00000000..60507fab --- /dev/null +++ b/open_issues/serverbootv2.mdwn @@ -0,0 +1,901 @@ +[[!meta copyright="Copyright © 2024 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]]."]]"""]] + + +# ServerBootV2 RFC Draft + +[[!inline pagenames=hurd/what_is_an_os_bootstrap raw=yes feeds=no]] + +Sergey Bugaev proposed: + +The Hurd's current bootstrap, [[Quiet-Boot|hurd/bootstrap]] (a biased +and made-up name), is fragile, hard to debug, and complicated: + +* `Quiet-boot` chokes on misspelled or missing boot arguments. When + this happens, the Hurd bootstrap will likely hang and display + nothing. This is tricky to debug. +* `Quiet-Boot` is hard to change. For instance, when the Hurd + developers added `acpi`, the `pci-arbiter`, and `rumpdisk`, they + struggled to get `Quiet-Boot` working again. +* `Quiet-Boot` forces each bootstrap task to include special bootstrap + logic to work. This limits what is possible during the + bootstrap. For instance, it should be trivial for the Hurd to + support netboot, but `Quiet-Boot` makes it hard to add `nfs`, + `pfinet`, and `isofs` to the bootstrap. +* `Quiet-Boot` hurts other Hurd distributions too. When Guix + developers updated their packaged version of the Hurd, that included + support for SATA drives, a simple misspelled boot argument halted + their progress for a few weeks. + +The alternative `ServerBoot V2` proposal (which was discussed on +[irc](https://logs.guix.gnu.org/hurd/2023-07-18.log) and is similar to +the previously discussed [bootshell +proposal](https://mail-archive.com/bug-hurd@gnu.org/msg26341.html)) +aims to code all or most of the bootstrap specific logic into one +single task (`/hurd/serverboot`). `Serverboot V2` has a number +of enticing advantages: + +* It simplifies the hierarchical dependency of translators during + bootstrap. Developers should be able to re-order and add new + bootstrap translators with minimal work. +* It gives early bootstrap translators like `auth` and `ext2fs` + standard input and output which lets them display boot errors. It + also lets signals work. +* One can trivially use most Hurd translators during the + bootstrap. You just have to link them statically. +* `libmachdev` could be simplified to only expose hardware to + userspace; it might even be possible to remove it entirely. Also + the `pci-arbiter`, `acpi`, and `rumpdisk` could be simplified. +* Developers could remove any bootstrap logic from `libdiskfs`, which + detects the bootstrap filesystem, starts the `exec` server, and + spawns `/hurd/startup`. Instead,`libdiskfs` would only focus on + providing filesystem support. +* If an error happens during early boot, the user could be dropped + into a REPL or mini-console, where he can try to debug the issue. + We might call this `Bootshell V2`, in reference to the original + proposal. This could be written in lisp. Imagine having an + extremely powerful programming language available during bootstrap + that is only [436 bytes!](https://justine.lol/sectorlisp2) +* It would simplify the code for subhurds by removing the logic from + each task that deals with the OS bootstrap. + +Now that you know why we should use `Serverboot V2`, let's get more +detailed. What is `Serverboot V2` ? + +`Serverboot V2` would be an empty filesystem dynamically populated +during bootstrap. It would use a `netfs` like filesystem that will +populate as various bootstrap tasks are started. For example, +`/servers/socket2` will be created once `pfinet` starts. It also +temporarily pretends to be the Hurd process server, `exec`, and `/` +filesystem while providing signals and `stdio`. Let's explain how +`Serverboot V2` will bootstrap the Hurd. + +**FIXME The rest of this needs work.** + +Any bootstrap that the Hurd uses will probably be a little odd, +because there is an awkward and circular startup-dance between +`exec`, `ext2fs`, `startup`, `proc`, `auth`, the `pci-arbiter`, +`rumpdisk`, and `acpi` in which each translator oddly depends on the +other during the bootstrap, as this ascii art shows. + + + pci-arbiter + | + acpi + | + rumpdisk + | + ex2fs -- storeio + / \ + exec startup + / \ + auth proc + + +This means that there is no *perfect* Hurd bootstrap design. Some +designs are better in some ways and worse in others. `Serverboot V2` +would simplify other early bootstrap tasks, but all that complicated +logic would be in one binary. One valid criticism of `Serverboot V2` +is that it will may be a hassle to develop and maintain. In any case, +trying to code the *best* Hurd bootstrap may be a waste of time. In +fact, the Hurd bootstrap has been rewritten several times already. +Our fearless leader, Samuel, feels that rewriting the Hurd bootstrap +every few years may be a waste of time. Now that you understand why +Samuel's discourages a Hurd bootstrap rewrite, let's consider why we +should develop `Serverboot V2`. + +# How ServerBoot V2 will work + +Bootstrap begins when Grub and GNU Mach start some tasks, and then GNU +Mach resumes the not-yet-written +`/hurd/serverboot`. `/hurd/serverboot` is the only task to accept +special ports from the kernel via command line arguments like +`--kernel-task`; `/hurd/serverboot` tries to implement/emulate as much +of the normal Hurd environment for the other bootstrap translators. +In particular, it provides the other translators with `stdio`, which +lets them read/write without having to open the Mach console device. +This means that the various translators will be able to complain about +their bad arguments or other startup errors, which they cannot +currently do. + +`/hurd/serverboot` will provide a basic filesystem with netfs, which +gives the other translators a working `/` directory and `cwd` +ports. For example, `/hurd/serverboot`, would store its port at +`/dev/netdde`. When `/hurd/netdde` starts, it will reply to its +parent with `fsys_startup ()` as normal. + +`/hurd/serverboot` will also emulate the native Hurd process server to +early bootstrap tasks. This will allow early bootstrap tasks to get +the privileged (device master and kernel task) ports via the normal +glibc function `get_privileged_ports (&host_priv, &device_master).` +Other tasks will register their message ports with the emulated +process server. This will allow signals and messaging during the +bootstrap. We can even use the existing mechanisms in glibc to set and +get init ports. For example, when we start the `auth` server, we will +give every task started thus far, their new authentication port via +glibc's `msg_set_init_port ()`. When we start the real proc server, +we query it for proc ports for each of the tasks, and set them the +same way. This lets us migrate from the emulated proc server to the +real one. + +**Fix me: Where does storeio (storeio with** +`device:@/dev/rumpdisk:wd0`**), rumpdisk, and the pci-arbiter come +in?** + +Next, we start `ext2fs`. We reattach all the running translators from +our `netfs` bootstrap filesystem onto the new root. We then send +those translators their new root and cwd ports. This should happen +transparently to the translators themselves! + +# Supporting Netboot + +`Serverboot V2` could trivially support netboot by adding `netdde`, +`pfinet` (or `lwip`), and `isofs` as bootstrap tasks. The bootstrap +task will start the `pci-arbiter`, and `acpi` (FIXME add some more +detail to this sentence). The bootstrap task starts `netdde`, which +will look up any `eth` devices (using the device master port, which it +queries via the fake process server interface), and sends its fsys +control port to the bootstrap task in the regular `fsys_startup +()`. The bootstrap task sets the fsys control port as the translator +on the `/dev/netdde` node in its `netfs` bootstrap fs. Then +`/hurd/serverboot` resumes `pfinet`, which looks up +`/dev/netdde`. Then `pfinet` returns its `fsys` control port to the +bootstrap task, which it sets on `/servers/socket/2`. Then bootstrap +resumes `nfs`, and `nfs` just creates a socket using the regular glibc +socket () call, and that looks up `/servers/socket/2`, and it just +works. **FIXME where does isofs fit in here?** + +Then `nfs` gives its `fsys` control port to `/hurd/serverboot`, which +knows it's the real root filesystem, so it take the netdde's and +pfinet's fsys control ports. Then it calls `file_set_translator ()` +on the nfs on the same paths, so now `/dev/netdde` and +`/servers/socket/2` exist and are accessible both on our bootstrap fs, +and on the new root fs. The bootstrap can then take the root fs to +broadcast a root and cwd port to all other tasks via a +`msg_set_init_port ()`. Now every task is running on the real root fs, +and our little bootstrap fs is no longer used. + +`/hurd/serverboot` can resume the exec server (which is the first +dynamically-linked task) with the real root fs. Then we just +`file_set_translator ()` on the exec server to `/servers/exec`, so +that `nfs` doesn't have to care about this. The bootstrap can now +spawn tasks, instead of resuming ones loaded by Mach and grub, so it +next spawns the `auth` and `proc` servers and gives everyone their +`auth` and `proc` ports. By that point, we have enough of a Unix +environment to call `fork()` and `exec()`. Then the bootstrap tasks +would do the things that `/hurd/startup` used to do, and finally +spawns (or execs) `init / PID 1`. + +With this scheme you will be able to use ext2fs to start to your root +fs via as `/hurd/ext2fs.static /dev/wd0s1`. This eliminates boot +arguments like `--magit-port` and `--next-task`. + +This also simplifies `libmachdev`, which exposes devices to userspace +via some Mach `device_*` RPC calls, which lets the Hurd contain device +drivers instead of GNU Mach. Everything that connects to hardware can +be a `machdev`. + +Additionally, during the `Quiet Boot` bootstrap,`libmachdev` awkwardly +uses `libtrivfs` to create a transient `/` directory, so that the +`pci-arbiter` can mount a netfs on top of it at bootstrap. +`libmachdev` needs `/servers/bus` to mount `/pci,`and it also +needs `/servers` and `/servers/bus` (and `/dev`, and +`/servers/socket`). That complexity could be moved to `ServerbootV2`, +which will create directory nodes at those locations. + +`libmachdev` provides a trivfs that intercepts the `device_open` rpc, +which the `/dev` node uses. It also fakes a root filesystem node, so +you can mount a `netfs` onto it. You still have to implement +`device_read` and `device_write` yourself, but that code runs in +userspace. An example of this can be found in +`rumpdisk/block-rump.c`. + +`libpciaccess` is a special case: it has two modes, the first time it +runs via `pci-arbiter`, it acquires the pci config IO ports and runs +as x86 mode. Every subsequent access of pci becomes a hurdish user of +pci-arbiter. + +`rumpdisk` exposes `/dev/rumpdisk`: + +``` +$ showtrans /dev/rumpdisk + /hurd/rumpdisk +``` + + +# FAQ + +## `Server Boot V2` looks like a ramdisk + a script...? + +Its not quite a ramdisk, its more a netfs translator that +creates a temporary `/`. Its a statically linked binary. I don't +think it differs from a multiboot module. + +## How are the device nodes on the bootstrap netfs attached to each translator? +## How does the first non-bootstrap task get invoked? +## does bootstrap resume it? +## Could we just use a ram disk instead? +## One could stick an unionfs on top of it to load the rest of the system after bootstrap. + +It looks similar to a ramdisk in principle, i.e. it exposes a fs which +lives only in ram, but a ramdisk would not help with early bootstrap. +Namely during early bootstrap, there are no signals or console. +Passing control from from one server to the next via a bootstrap port +is a kludge at best. How many times have you seen the bootstrap +process hang and just sit there? `Serverboot V2` would solve that. +Also, it would allow subhurds to be full hurds without special casing +each task with bootstrap code. It would also clean up `libmachdev`, +and Damien, its author, is in full support. + +## A ramdisk could implement signals and stdio. Isn't that more flexible? + +But if its a ramdisk essentially you have to provide it with a tar +image. Having it live inside a bootstrap task only is +preferable. Also the task could even exit when its done whether you +use an actual ramdisk or not. You still need to write the task that +boots the system. That is different than how it works currently. Also +a ramdisk would have to live in mach, and we want to move things out +of mach. + +Additionally, the bootstrap task will be loaded as the first multiboot +module by grub. It's not a ramdisk, because a ramdisk has to contain +some fs image (with data), and we'd need to parse that format. It +might make sense to steer it more into that direction (and Samuel +seems to have preferred it), because there could potentially be some +config files, or other files that the servers may need to run. I'm not +super fond of that idea. I'd prefer the bootstrap fs to be just a +place where ports (translators) can be placed and looked up. Actually +in my current code it doesn't even use `netfs`, it just implements the +RPCs directly. I'll possibly switch to `netfs` later, or if the +implementation stays simple, I won't use `netfs`. + +## Serverboot V2 just rewrites proc and exec. Why reimplement so much code? + +I don't want to exactly reimplement full `proc` and `exec` servers in the +bootstrap task, it's more of providing very minimal emulation of some +of their functions. I want to implement the two RPCs from the +`proc` interface, one to give a task the privileged ports on request and +one to let the task give me its msg port. That seems fairly simple to +me. + +While we were talking of using netfs, my actual implementation doesn't +even use that, it just implements the RPCs directly (not to suggest I +have anything resembling a complete implementation). Here's some +sample code to give you an idea of what it is like + + + error_t + S_proc_getprivports (struct bootstrap_task *task, + mach_port_t *host_priv, + mach_port_t *device_master) + { + if (!task) + return EOPNOTSUPP; + + if (bootstrap_verbose) + fprintf (stderr, "S_proc_getprivports from %s\n", task->name); + + *host_priv = _hurd_host_priv; + *device_master = _hurd_device_master; + + return 0; + } + + error_t + S_proc_setmsgport (struct bootstrap_task *task, + mach_port_t reply_port, + mach_msg_type_name_t reply_portPoly, + mach_port_t newmsgport, + mach_port_t *oldmsgport, + mach_msg_type_name_t *oldmsgportPoly) + { + if (!task) + return EOPNOTSUPP; + + if (bootstrap_verbose) + fprintf (stderr, "S_proc_setmsgport for %s\n", task->name); + + *oldmsgport = task->msgport; + *oldmsgportPoly = MACH_MSG_TYPE_MOVE_SEND; + + task->msgport = newmsgport; + + return 0; + } + +Yes, it really is just letting tasks fetch the priv ports (so +`get_privileged_ports ()` in glibc works) and set their message ports. +So much for a slippery slope of reimplementing the whole process +server :) + + +## Let's bootstrap like this: initrd, proc, exec, acpi, pci, drivers, +## unionfs+fs with every server executable included in the initrd tarball? + +I don't see how that's better, but you would be able to try something +like that with my plan too. The OS bootstrap needs to start servers +and integrate them into the eventual full hurd system later when the +rest of the system is up. When early servers start, they're running +on bare Mach with no processes, no `auth`, no files or file +descriptors, etc. I plan to make files available immediately (if not +the real fs), and make things progressively more "real" as servers +start up. When we start the root fs, we send everyone their new root +`dir` port. When we start `proc`, we send everyone their new `proc` +port. and so on. At the end, all those tasks we have started in +early boot are full real hurd proceses that are not any different to +the ones you start later, except that they're statically linked, and +not actually `io map`'ed from the root fs, but loaded by Mach/grub +into wired memory. + +# IRC Logs + + <damo22> showtrans /dev/wd0 and you can open() that node and it will + act as a device master port, so you can then `device_open` () devices + (like wd0) inside of it, right? + + oh it's a storeio, that's… cute. that's another translator we'd need + in early boot if we want to boot off /hurd/ext2fs.static /dev/wd0 + + <damo22> We implemented it as a storeio with + device:@/dev/rumpdisk:wd0 + + so the `@` sign makes it use the named file as the device master, right? + + <damo22> the `@` symbol means it looks up the file as the device + master yes. Instead of mach, but the code falls back to looking up + mach, if it cant be found. + + I see it's even implemented in libstore, not in storeio, so it just + does `file_name_lookup ()`, then `device_open` on that. + + <damo22> pci-arbiter also needs acpi because the only way to know the + IRQ of a pci device reliably is to use ACPI parser, so it totally + implements the Mach `device_*` functions. But instead of handling the + RPCs directly, it sets the callbacks into the + `machdev_device_emulations_ops` structure and then libmachdev calls + those. Instead of implementing the RPCs themselves, It abstracts them, + in case you wanted to merge drivers. This would help if you wanted + multiple different devices in the same translator, which is of course + the case inside Mach, the single kernel server does all the devices. + + but that shouldn't be the case for the Hurd translators, right? we'd + just have multiple different translators like your thing with rumpdisk + and rumpusb. + + `<damo22>` i dont know + + ok, so other than those machdev emulation dispatch, libmachdev uses + trivfs and does early bootstrap. pci-arbiter uses it to centralize the + early bootstrap so all the machdevs can use the same code. They chain + together. pci-arbiter creates a netfs on top of the trivfs. How + well does this work if it's not actually used in early bootstrap? + + <damo22> and rumpdisk opens device ("pci"), when each task is resumed, + it inherits a bootstrap port + + and what does it do with that? what kind of device "pci" is? + + <damo22> its the device master for pci, so rumpdisk can call + pci-arbiter rpcs on it + + hm, so I see from the code that it returns the port to the root of its + translator tree actually. Does pci-arbiter have its own rpcs? does it + not just expose an fs tree? + + <damo22> it has rpcs that can be called on each fs node called + "config" per device: hurd/pci.defs. libpciaccess uses these. + + how does that compare to reading and writing the fs node with regular read and write? + + <damo22> so the second and subsequent instances of pciaccess end up + calling into the fs tree of pci-arbiter. you can't call read/write on + pci memory its MMIO, and the io ports need `inb`, `inw`, etc. They + need to be accessed using special accessors, not a bitstream. + + but I can do $ hexdump /servers/bus/pci/0000/00/02/0/config + + <damo22> yes you can on the config file + + how is that different from `pci_conf_read` ? it calls that. + + <damo22> the `pci fs` is implemented to allow these things. + + why is there a need for `pci_conf_read ()` as an RPC then, if you can + instead use `io_read` on the "config" node? + + <damo22> i am not 100% sure. I think it wasn't fully implemented from + the beginning, but you definitely cannot use `io_read ()` on IO + ports. These have explicit x86 instructions to access them + MMIO. maybe, im not sure, but it has absolute physical addressing. + + I don't see how you would do this via `pci.defs` either? + + <damo22> We expose all the device tree of pci as a netfs + filesystem. It is a bus of devices. you may be right. It would be best + to implement pciaccess to just read/write from the filesystem once its + exposed on the netfs. + + yes, the question is: + + 1 is there anything that you can do by using the special RPCs from + pci.defs that you cannot do by using the regular read/write/ls/map + on the exported filsystem tree, + 2 if no, why is there even a need for `pci.defs`, why not always use + the fs? But anyway, that's irrelevant for the question of bootstrap + and libmachdev + + <damo22> There is a need for rpcs for IO ports. + + Could you point me to where rumpdisk does `device_open ("pci")`? grep + doesn't show anything. which rpcs are for the IO ports? + + <damo22> They're not implemented yet we are using raw access I + think. The way it works, libmachdev uses the next port, so it all + chains together: `libmachdev/trivfs_server.c`. + + but where does it call `device_open ("pci")` ? + + <damo22> when the pci task resumes, it has a bootstrap port, which is + passed from previous task. There is no `device_open ("pci")`. or if + its the first task to be resumed, it grabs a bootstrap port from + glibc? im not sure + + ok, so if my plan is implemented how much of `libmachdev` functionality + will still be used / useful? + + <damo22> i dont know. The mach interface? device interface\*. maybe + it will be useless. + + I'd rather you implemented the Mach device RPCs directly, without the + emulation structure, but that's an unrelated change, we can leave that + in for now. + + <damo22> I kind of like the emulation structure as a list of function + pointers, so i can see what needs to be implemented, but that's + neither here nor there. `libmachdev` was a hack to make the bootstrap + work to be honest.…and we'd no longer need that. I would be happy if + it goes away. the new one would be so much better. + + is there anything else I should know about this all? What else could + break if there was no libmachdev and all that? + + <damo22> acpi, pci-arbiter, rumpdisk, rumpusbdisk + + right, let's go through these + + <damo22> The pci-arbiter needs to start first to claim the x86 config + io ports. Then gnumach locks these ports. No one else can use them. + + so it starts and initializes **something** what does it need? the + device master port, clearly, right? that it will get through the + glibc function / the proc API + + <damo22> it needs a /servers/bus and the device master + + <solid_black> + right, so then it just does fsys_startup, and the bootstrap task + places it onto `/servers/bus` (it's not expected to do + `file_set_translator ()` itself, just as when running as a normal + translator) + + <damo22> it exposes a netfs on `/servers/bus/pci` + + <solid_black> so will pci-arbiter still expose mach devices? a mach + device master? or will it only expose an fs tree + pci.defs? + + <damo22> i think just fs tree and pci.defs. should be enough + + <solid_black> ok, so we drop mach dev stuff from pci-arbiter + completely. then acpi starts up, right? what does it need? + + <damo22> It needs access to `pci.defs` and the pci tree. It + accesses that via libpciaccess, which calls a new mode that + accesses the fstree. It looks up `servers/bus/pci`. + + ok, but how does that work now then? + + <damo22> It looks up the right nodes and calls pci.defs on them. + + <solid_black> looks up the right node on what? there's no root + filesystem at that point (in the current scheme) + + `<damo22>` It needs pci access + + that's why I was wondering how it does `device_open ("pci")` + + <damo22> I think libmachdev from pci gives acpi the fsroot. there is a + doc on this. + + so does it set the root node of pci-arbiter as the root dir of acpi? + as in, is acpi effectively chrooted to `/servers/bus/pci`? + + <damo22> i think acpi is chrooted to the parent of /servers. It shares + the same root as pci's trivfs. + + i still don't quite understand how netfs and trivfs within pci-arbiter interact. + + <damo22> you said there would be a fake /. Can't acpi use that? + + <solid_black> yeah, in my plan / the new bootstrap scheme, there'll be + a / from the very start. + + <damo22> ok so acpi can look up /servers/bus/pci, and it will exist. + + and pci-arbiter can really sit on `/servers/bus/pci` (no need for + trivfs there at all) and acpi will just look up + `/servers/bus/pci`. And we do not need to change anything in acpi to + get it to do that. + + And how does it do it now? maybe we'd need to remove some + no-longer-required logic from acpi then? + + <damo22> it looks up device ("pci") if it exists, otherwise it falls + back to `/servers/bus/pci`. + + Ah hold on, maybe I do understand now. currently pci-arbiter exposes + its mach dev master as acpi-s mach dev master. So it looks up + device("pci") and finds it that way. + + <damo22> correct, but it doesnt need that if the `/` exists. + + yeah, we could remove this in the new bootstrap scheme, and just + always open the fs node (or leave it in for compatibility, we'll see + about that). acpi just sits on `/servers/acpi/tables`. + + `rumpdisk` runs next and it needs `/servers/bus/pci`, `pci.defs`, and + `/servers/acpi/tables`, and `acpi.defs`. It exposes `/dev/rumpdisk`. + + Would it make sense to make rumpdisk expose a tree/directory of Hurd + files and not Mach devices? This is not necessary for anything, but + just might be a nice little cleanup. + + <damo22> well, it could expose a tree of block devices, like + `/dev/rumpdisk/ide/1`. + + <solid_black> and then `ln -s /rumpdisk/ide/1 /dev/wd1`. and no need + for an intermediary storeio. plus the Hurd file interface is much + richer than Mach device, you can do fsync for instance. + + <damo22> the rump kernel is bsd under the hood, so needs to be + `/dev/rumpdisk/ide/wd0` + + <solid_black> You can just convert "ide/0" to "/dev/wd0" when + forwarding to the rump part. Not that I object to ide/wd0, but we can + have something more hierarchical in the exposed tree than old-school + unix device naming? Let's not have /dev/sda1. Instead let's have + /dev/sata/0/1, but then we'd still keep the bsd names as symlinks into + the *dev/rumpdisk*… tree + + <damo22> sda sda1 + + <solid_black> good point + + <damo22> 0 0/1 + + <solid_black> well, you can on the Hurd :D and we won't be doing that + either, rumpdisk only exposes the devices, not partitions + + <damo22> well you just implement a block device on the directory? but + that would be confusing for users. + + <solid_black> I'd expect rumpdisk to only expose device nodes, like + /dev/rumpdisk/ide/0, and then we'd have /dev/wd0 being a symlink to + that. And /dev/wd0s1 being a storeio of type part:1:/dev/wd0 or + instead of using that, you could pass that as an option to your fs, + like ext2fs -T typed part:1/dev/wd0 + + <damo22> where is the current hurd bootstrap (QuietBoot) docs hosted? + here: + https://git.savannah.gnu.org/cgit/hurd/web.git/plain/hurd/bootstrap.mdwn + + <solid_black> so yeah, you could do the device tree thing I'm + proposing in rumpdisk, or you could leave it exposing Mach devices and + have a bunch of storeios pointing to that. So anyway, let's say + rumpdisk keeps exposing a single node that acts as a Mach device + master and it sits on /dev/rumpdisk. + + <solid_black> Then we either need a storeio, or we could make ext2fs + use that directly. So we start `/hurd/ext2fs.static -T typed + part:1:@/dev/rumpdisk:wd0`. + + <solid_black> I'll drop all the logic in libdiskfs for detecting if + it's the bootstrap filesystem, and starting the exec server, and + spawning /hurd/startup. It'll just be a library to help create + filesystems. + + <solid_black> After that the bootstrap task migrates all those + translator nodes from the temporary / onto the ext2fs, broadcasts the + root and cwd ports to everyone, and off we go to starting auth and + proc and unix. sounds like it all would work indeed. so we're just + removing libmachdev completely, right? + + <damo22> netdde links to it too. I think it has libmachdevdde + + <solid_black> Also how would you script this thing. Like ideally we'd + want the bootstrap task to follow some sort of script which would say, + for example, + + mkdir /servers + mkdir /servers/bus + settrans /servers/bus/pci ${pci-task} --args-to-pci + mkdir /dev + settrans /dev/netdde ${netdde-task} --args-to-netdde + setroot ${ext2fs-task} --args-to-ext2fs + + <solid_black> and ideally the bootstrap task would implement a REPL + where you'd be able to run these commands interactively (if the + existing script fails for instance). It can be like grub, where it has + a predefined script, and you can do something (press a key combo?) to + instead run your own commands in a repl. or if it fails, it bails out + and drops you into the repl, yes. this gives you **so much more** + visibility into the boot process, because currently it's all scattered + across grub, libdiskfs (resuming exec, spawning /hurd/startup), + /hurd/startup, and various tricky pieces of logic in all of these + servers. + + <solid_black> We could call the mini-repl hurdhelper? If something + fails, you're on your own, at best it prints an error message (if the + failing task manages to open the mach console at that point) Perhaps + we call the new bootstrap proposal Bootstrap. + + <solid_black> When/if this is ready, we'll have to remove libmachdev + and port everything else to work without it. + + <damo22> yes its a great idea. I'm not a fan of lisp either. If i + keep in mind that `/` is available early, then I can just clean up the + other stuff. and assume i have `/`, and the device master can be + accessed with the regular glibc function, and you can printf freely + (no need to open the console). Do i need to run `fsys_startup` ? + + yes, exactly like all translators always do. Well you probably run + netfs_startup or whatever, and it calls that. you're not supposed to + call fsys_getpriv or fsys_init + + <damo22> i think my early attempts at writing translators did not use + these, because i assumed i had `/`. Then i realised i didn\`t. And + libmachdev was born. + + <solid-black> Yes, you should assume you have /, and just do all the + regular things you would do. and if something that you would usually + do doesn't work, we should think of a way to make it work by adding + more stuff in the bootstrap task when it's reasonable to, of + course. and please consider exposing the file tree from rumpdisk, + though that's orthogonal. + + <damo22> you mean a tree of block devices? + + <solid_black> Yes, but each device node would be just a Hurd (device) + file, not a Mach device. i.e. it'd support io_read and io_write, not + device_read and device_write. well I guess you could make it support + both. + + <damo22> isnt that storeio's job? + + <solid_black> if a node only implements the device RPCs, we need a + storeio to turn it into a Hurd file, yes. but if you would implement + the file RPCs directly, there wouldn't be a need for the intermediary + storeio, not that it's important. + + <damo22> but thats writing storeio again. thing is, i dont know at + runtime which devices are exposed by rump. It auto probes them and + prints them out but i cant tell programmatically which ones were + detected, becuause rump knows which devices exist but doesn't expose + it over API in any way. Because it runs as a kernel would with just + one driver set. + + <damo22> Rump is a decent set of drivers. It does not have better + hardware support than Linux drivers (of modern Linux)? Instead Rump is + netbsd in a can, and it's essentially unmaintained upstream + too. However, it still is used it to test kernel modules, but it lacks + makefiles to separate all drivers into modules. BUT using rump is + better than updating / redoing the linux drivers port of DDE, because + netbsd internal kernel API is much much more stable than linux. We + would fall behind in a week with linux. No one would maintain the + linux driver -> hurd port. Also, there is a framework that lets you + compile the netbsd drivers as userspace unikernels: rump. Such a + thing only does not exist for modern Linux. Rump is already good + enough for some things. It could replace netdde. It already works for + ide/sata. + + <damo22> Rump it has its own /dev nodes on a rumpfs, so you can do + something like `rump_ls` it. + + <damo22> Rump is a minimal netbsd kernel. It is just the device + drivers, and a bit of pthreading, and has only the drivers that you + link. So rumpdisk only has the ahci and ide drivers and nothing + else. Additionally rump can detect them off the pci bus. + + <damo22> I will create a branch on + <http://git.zammit.org/hurd-sv.git> with cleaned translators. + + <damo22> solid_black: i almost cleaned up acpi and pci-arbiter but + realised they are missing the shutdown notification when i strip out + libmachdev. + + <solid-black>: "how are the device nodes on the bootstrap netfs attached to + each translator?" – I don't think I understand the question, please + clarify. + + <damo22> I was wondering if the new bootstrap process can resume a fs + task and have all the previous translators wake up and serve their + rpcs. without needing to resume them. we have a problem with the + current design, if you implement what we discussed yesterday, the IO + ports wont work because they are not exposed by pci-arbiter yet. I am + working on it, but its not ready. + + <solid_black> I still don't understand the problem. the bootstrap + task resumes others in order. the root fs task too, eventually, but + not before everything that hash to come up before the root fs task is + ready. + + <damo22> I don't think it needs to be a disk. Literally a trivfs is enough. + + <solid_black> why are I/O ports not exposed by pci-arbiter? why isn't + that in issue with how it works currently then? + + <damo22> solid_black: we are using ioperm() in userspace, but i want + to refactor the io port usage to be granularly accessed. so one day + gnumach can store a bitmap of all io ports and reject more than one + range that overlaps ports that are in use. since only one user of any + port at any time is allowed. i dont know if that will allow users to + share the same io ports, but at least it will prevent users from + clobbering each others hw access. + + <solid_black> damo22: (again, sorry for not understanding the hardware + details), so what would be the issue? when the pci arbiter starts, + doesn't it do all the things it has to do with the I/O ports? + + <damo22> io ports are only accessed in raw method now. Any user can do + ioperm(0, 0xffff, 1) and get access to all of them + + <solid_black> doesn't that require host priv or something like that? + + <damo22> yeh probably. maybe only root can. But i want to allow + unprivileged users to access io ports by requesting exclusive access + to a range. + + <solid_black> I see that ioperm () in glibc uses the device master + port, so yeah, root-only (good) + + `<damo22>` first in locks the port range + + <solid_black> but you're saying that there's someting about these I/O + ports that works today, but would break if we implemented what we + discussed yeasterday? what is it, and why? + + `<damo22>` well it might still work. but there's a lot of changes to + be done in general + + <solid_black> let me try to ask it in a different way then + + <damo22> i just know a few of the specifics because i worked on them. + + <solid_black> As I understand it, you're saying that 1: currently any + root process can request access to any range of I/O ports, and you + also want to allow **unprivileged** processes to get access to ranges + of I/O ports, via a new API of the PCI arbiter (but this is not + implemented yet, right?) + + <damo22> yes + + <solid_black> 2: you're saying that something about this would break / + be different in the new scheme, compared to the current scheme. i + don't understand the 2, and the relation between 1 and 2. + + <damo22> 2 not really, I may have been mistaken it probably will + continue working fine. until i try to implement 1. ioperm calls + `i386_io_perm_create` and `i386_io__perm_modify` in the same system + call. I want to seperate these into the arbiter so the request goes + into pci-arbiter and if it succeeds, then the port is returned to the + caller and the caller can change the port access. + + <solid_black> yes, so what about 2 will break 1 when you try to implement it? + + <damo22> with your new bootstrap, we need `i386_io_perm_*` to be + accessible. im not sure how. is that a mach rpc? + + <solid_black> these are mach rpcs. i386_io_perm_create is an rpc that + you do on device master. + + <damo22> should be ok then + + <solid_black> i386_io_perm_modify you do on you task port. yes, I + don't see how this would be problematic. + + <damo22>: you might find this branch useful + <http://git.zammit.org/hurd-sv.git/log/?h=feat-simplify-bootstrap> + + <solid_black> although: + + 1. I'm not sure whether the task itself should be wiring its memory, + or if the bootstrap task should do it. + 2. why do you request startup notifications if you then never do + anything in `S_startup_dosync`? + + <solid_black> same for essential tasks actaully, that should probably + be done by the bootstrap task and not the translator itself (but we'll + see) + + <solid_black> 1. don't `mach_print`, just `fprintf (stderr, "")` + <solid_black> 2. please always verify the return result of + `mach_port_deallocate` (and similar functions), + typically like this: + + err = mach_port_deallocate (…); + assert_perror_backtrace (err); + + this helps catch nasty bugs. + + <solid_black> 3. I wonder why both acpi and pci have their own + `pcifs_startup` and `acpifs_startup`; can't they use `netfs_startup + ()`? + + `<damo22>` 1. no idea, 2. rumpdisk needed it, but these might + not 3. ACK, 4.ACK, 5. I think they couldnt use the `netfs_startup ()` + before but might be able to now. Anyway, this should get you booting + with your bootstrap translator (without rumpdisk). Rumpdisk seems to + use the `device_* RPC` from `libmachdev` to expose its device. + whereas pci and acpi dont use them for anything except `device_open` + to pass their port to the next translator. I think my latest patch + for io ports will work. but i need to rebuild glibc and libpciaccess + and gnumach. Why does libhurduser need to be in glibc? It's quite + annoying to add an rpc. + + I think i have done gnumach io port locking, and pciaccess, but hurd + part needs work and then to merge it needs a rebuild of glibc because + of hurduser + + <damo22> Why cant libhurduser be part of the hurd package? + + I don't think I understnad enough of this to do a review, but I'd + still like to see the patch if it's available anywhere. + + <damo22> ok i can push to my repos + + <solid_black> glibc needs to use the Hurd RPCs (and implement some, + too), and glibc cannot depend on the Hurd package because the Hurd + package depends on glibc. + + <damo22> lol ok + + <solid_black> As things currently stand, glibc depends on the Hurd + **headers** (including mig defs), but not any Hurd binaries. still, + the cross build process is quite convoluted. I posted about it + somewhere: https://floss.social/@bugaevc/109383703992754691 + + <jpoiret> the manual patching of the build system that's needed to + bootstrap everything is a bit suboptimal. + + <damo22> what if you guys submit patches upstream to glibc to add a + build target to copy the headers or whatever is needed? solid_black: + see + [http://git.zammit.org/{libpciaccess.git,gnumach.git](http://git.zammit.org/%7Blibpciaccess.git,gnumach.git)} + on fix-ioperm branches diff --git a/open_issues/smp.mdwn b/open_issues/smp.mdwn index 6496f388..b0287a48 100644 --- a/open_issues/smp.mdwn +++ b/open_issues/smp.mdwn @@ -289,7 +289,7 @@ maillist](https://lists.gnu.org/archive/html/bug-hurd/2018-08/msg00048.html) - [Initial thread in bug-hurd maillist](https://lists.gnu.org/archive/html/bug-hurd/2018-06/msg00048.html) - [SMP in GNU/Hurd FAQ](https://www.gnu.org/software/hurd/faq/smp.html) -- [GNU Mach git repository](http://git.savannah.gnu.org/cgit/hurd/gnumach.git) +- [GNU Mach git repository](https://git.savannah.gnu.org/cgit/hurd/gnumach.git) - [GNU Mach reference manual](https://www.gnu.org/software/hurd/gnumach-doc/) - [**MultiProcessor Specification**](https://pdos.csail.mit.edu/6.828/2011/readings/ia32/MPspec.pdf) - [**ACPI Specification**](http://www.uefi.org/sites/default/files/resources/ACPI%206_2_A_Sept29.pdf) diff --git a/open_issues/sync_but_still_unclean_filesystem.mdwn b/open_issues/sync_but_still_unclean_filesystem.mdwn deleted file mode 100644 index eae98077..00000000 --- a/open_issues/sync_but_still_unclean_filesystem.mdwn +++ /dev/null @@ -1,39 +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]]."]]"""]] - -[[!tag open_issue_gnumach open_issue_hurd]] - -Also filed as [[!GNU_Savannah_bug 29292]]. - -\#hurd, 2010, end of May / beginning of June - - [runnign sync, but sill unclean filesystem at next boot] - <slpz> guillem: when libpager syncs an object, it sends an m_o_lock_request - and waits (if the synchronous argument was specified) for a - m_o_lock_completed. But m_o_lock_completed only means that dirty pages - have been sent to the translator, and this one still needs to write them - to the backing storage - <slpz> guillem: there's no problem if sync() returns before actually - writting the changes to disk, but this also happens when shutting down - the translator - <slpz> guillem: in theory, locking mechanisms in libpager should prevent - this from happening by keeping track of write operations, but this seems - to fail in some situations - -It helps a lot to run [[`syncfs --synchronous /`|hurd/syncfs]] before issuing -the `halt` or `reboot` command. This will prevent most of the uncleanliness. -Of course, [[hurd/translator/ext2fs]] is meant to be doing this to-disk -synchronization internally upon translator shutdown, but evidently it doesn't -in all cases. - -Apparently diskfs simply does not set filesystems as read-only: -<http://lists.gnu.org/archive/html/bug-hurd/2011-08/msg00024.html>. - -A patch was applied, and the sync issue does not seem to happen any more. diff --git a/open_issues/systemd.mdwn b/open_issues/systemd.mdwn index dc8aa6e2..1055a196 100644 --- a/open_issues/systemd.mdwn +++ b/open_issues/systemd.mdwn @@ -9,8 +9,6 @@ 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_porting]] - * <http://www.freedesktop.org/wiki/Software/systemd> * <http://0pointer.de/blog/projects/systemd.html>, diff --git a/open_issues/time.mdwn b/open_issues/time.mdwn index 99c2cbe9..425a7a82 100644 --- a/open_issues/time.mdwn +++ b/open_issues/time.mdwn @@ -180,7 +180,7 @@ not get a define for `HZ`, which is then defined with a fallback value of 60. <braunr> keep in mind rpctrace doesn't behave like ptrace at all <braunr> it acts as a proxy <braunr> nalaginrut: - http://git.savannah.gnu.org/cgit/hurd/glibc.git/commit/?h=rbraun/getclktck_100_hz&id=90404d6d1aa01f6ce1557841f5a675bb6a30f508 + https://git.savannah.gnu.org/cgit/hurd/glibc.git/commit/?h=rbraun/getclktck_100_hz&id=90404d6d1aa01f6ce1557841f5a675bb6a30f508 <braunr> nalaginrut: you need to add it to the debian eglibc patch list, rebuild the packages, and install the resulting .debs <braunr> if you have trouble doing it, i'll make packages when i have time @@ -786,7 +786,7 @@ not get a define for `HZ`, which is then defined with a fallback value of 60. <braunr> 04:53 < nalaginrut> braunr: BTW, where is the patch/ <braunr> there is hardly anyone here at 5am <braunr> nalaginrut: - http://git.savannah.gnu.org/cgit/hurd/glibc.git/log/?h=rbraun/clock_t_centiseconds + https://git.savannah.gnu.org/cgit/hurd/glibc.git/log/?h=rbraun/clock_t_centiseconds <nalaginrut> braunr: thanks for that, but why not use a constant for 100? <braunr> nalaginrut: i don't know where to define it <braunr> it's glibc, you don't define new stuff mindlessly diff --git a/open_issues/cvs_todo_file.mdwn b/open_issues/todo.mdwn index a42e6dca..0ea5967a 100644 --- a/open_issues/cvs_todo_file.mdwn +++ b/open_issues/todo.mdwn @@ -9,10 +9,10 @@ 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="CVS TODO file"]] +[[!meta title="TODO file"]] [[!tag open_issue_hurd]] The canonical [TODO -file](http://savannah.gnu.org/cgi-bin/viewcvs/~checkout~/hurd/hurd/TODO?rev=HEAD&content-type=text/plain) -from the CVS archive. +file](https://git.savannah.gnu.org/cgit/hurd/hurd.git/plain/TODO) +from the git archive. |
