diff options
Diffstat (limited to 'open_issues')
47 files changed, 12404 insertions, 3102 deletions
diff --git a/open_issues/64-bit_port.mdwn b/open_issues/64-bit_port.mdwn index 9382a0d5..aa49e64b 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 + 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..9232186f 100644 --- a/open_issues/anatomy_of_a_hurd_system.mdwn +++ b/open_issues/anatomy_of_a_hurd_system.mdwn @@ -1050,12 +1050,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/binutils.mdwn b/open_issues/binutils.mdwn index 328cc24b..100fab32 100644 --- a/open_issues/binutils.mdwn +++ b/open_issues/binutils.mdwn @@ -33,7 +33,7 @@ though, as explained below. ## [[/GDB]] -GDB needs an processor architecture as well as operating system port. +GDB needs a processor architecture as well as an operating system port. # Configuration 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..dd5fa3d4 --- /dev/null +++ b/open_issues/copyright_assignment.mdwn @@ -0,0 +1,20 @@ +[[!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). +* Sergey Bugaev (case #1722866): sent form on 2021 May 8th, got answer on May 24th, immediately answered that there was an error in the actual family name. Eventually that was fixed, but the papers have the name in an order which is not proper for Russian law. Moved on with it. But hasn't had any answer during august and september. And then he got conscribed and so we won't have any news from him until around november 2022. +* 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..21661f02 100644 --- a/open_issues/emacs.mdwn +++ b/open_issues/emacs.mdwn @@ -12,1531 +12,30 @@ 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 - <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/smp.svg b/open_issues/images/smp.svg new file mode 100644 index 00000000..3b917bde --- /dev/null +++ b/open_issues/images/smp.svg @@ -0,0 +1,11208 @@ +<?xml version="1.0" encoding="UTF-8" standalone="no"?> +<!-- 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:xlink="http://www.w3.org/1999/xlink" + xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" + xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" + id="svg3004" + version="1.1" + inkscape:version="0.48.1 r9760" + width="993.86743" + height="639.2627" + xml:space="preserve" + sodipodi:docname="SMP - Symmetric Multiprocessor System.svg"><metadata + id="metadata3010"><rdf:RDF><cc:Work + rdf:about=""><dc:format>image/svg+xml</dc:format><dc:type + rdf:resource="http://purl.org/dc/dcmitype/StillImage" /><dc:title /></cc:Work></rdf:RDF></metadata><defs + id="defs3008"><linearGradient + id="linearGradient23576" + osb:paint="solid"><stop + style="stop-color:#000000;stop-opacity:1;" + offset="0" + id="stop23578" /></linearGradient><inkscape:path-effect + effect="spiro" + id="path-effect23402" + is_visible="true" /><linearGradient + id="linearGradient5729" + osb:paint="solid"><stop + style="stop-color:#ff0000;stop-opacity:1;" + offset="0" + id="stop5731" /></linearGradient><linearGradient + id="linearGradient5711" + osb:paint="solid"><stop + style="stop-color:#ff0000;stop-opacity:1;" + offset="0" + id="stop5713" /></linearGradient><linearGradient + id="linearGradient5705" + osb:paint="solid"><stop + style="stop-color:#ff0000;stop-opacity:1;" + offset="0" + id="stop5707" /></linearGradient><linearGradient + id="linearGradient4254" + osb:paint="solid"><stop + style="stop-color:#ff0000;stop-opacity:1;" + offset="0" + id="stop4256" /></linearGradient><linearGradient + id="linearGradient4248" + osb:paint="solid"><stop + style="stop-color:#ff0000;stop-opacity:1;" + offset="0" + id="stop4250" /></linearGradient><linearGradient + id="linearGradient4242" + osb:paint="solid"><stop + style="stop-color:#ff0000;stop-opacity:1;" + offset="0" + id="stop4244" /></linearGradient><linearGradient + id="linearGradient15272" + osb:paint="solid"><stop + style="stop-color:#fc0000;stop-opacity:1;" + offset="0" + id="stop15274" /></linearGradient><linearGradient + id="linearGradient13822" + osb:paint="solid"><stop + style="stop-color:#572382;stop-opacity:1;" + offset="0" + id="stop13824" /></linearGradient><inkscape:perspective + sodipodi:type="inkscape:persp3d" + inkscape:vp_x="0 : 131.64062 : 1" + inkscape:vp_y="0 : 1000 : 0" + inkscape:vp_z="626.21094 : 131.64062 : 1" + inkscape:persp3d-origin="313.10547 : 87.760417 : 1" + id="perspective12329" /><linearGradient + id="linearGradient6865" + osb:paint="solid"><stop + style="stop-color:#0f1800;stop-opacity:1;" + offset="0" + id="stop6867" /></linearGradient><linearGradient + id="linearGradient6859" + osb:paint="solid"><stop + style="stop-color:#0f1800;stop-opacity:1;" + offset="0" + id="stop6861" /></linearGradient><linearGradient + id="linearGradient33194" + osb:paint="solid"><stop + style="stop-color:#10110a;stop-opacity:1;" + offset="0" + id="stop33196" /></linearGradient><linearGradient + id="linearGradient33166" + osb:paint="solid"><stop + style="stop-color:#ff00f9;stop-opacity:1;" + offset="0" + id="stop33168" /></linearGradient><linearGradient + id="linearGradient29591" + osb:paint="gradient"><stop + style="stop-color:#000000;stop-opacity:1;" + offset="0" + id="stop29593" /><stop + style="stop-color:#000000;stop-opacity:0;" + offset="1" + id="stop29595" /></linearGradient><linearGradient + id="linearGradient29145" + osb:paint="solid"><stop + style="stop-color:#108000;stop-opacity:1;" + offset="0" + id="stop29147" /></linearGradient><marker + inkscape:stockid="Arrow2Lstart" + orient="auto" + refY="0" + refX="0" + id="Arrow2Lstart" + style="overflow:visible"><path + id="path4311" + style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round" + 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" + transform="matrix(1.1,0,0,1.1,1.1,0)" + inkscape:connector-curvature="0" /></marker><marker + inkscape:stockid="Arrow1Lend" + orient="auto" + refY="0" + refX="0" + id="Arrow1Lend" + style="overflow:visible"><path + id="path4296" + d="M 0,0 5,-5 -12.5,0 5,5 0,0 z" + style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt;marker-start:none" + transform="matrix(-0.8,0,0,-0.8,-10,0)" + inkscape:connector-curvature="0" /></marker><marker + inkscape:stockid="Arrow1Lstart" + orient="auto" + refY="0" + refX="0" + id="Arrow1Lstart" + style="overflow:visible"><path + id="path4293" + d="M 0,0 5,-5 -12.5,0 5,5 0,0 z" + style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt;marker-start:none" + transform="matrix(0.8,0,0,0.8,10,0)" + inkscape:connector-curvature="0" /></marker><linearGradient + id="linearGradient5616" + osb:paint="solid"><stop + style="stop-color:#b8bbad;stop-opacity:0.93333334;" + offset="0" + id="stop5618" /></linearGradient><linearGradient + id="linearGradient5588" + osb:paint="solid"><stop + style="stop-color:#1d0403;stop-opacity:1;" + offset="0" + id="stop5590" /></linearGradient><linearGradient + id="linearGradient5564" + osb:paint="solid"><stop + style="stop-color:#300a70;stop-opacity:1;" + offset="0" + id="stop5566" /></linearGradient><linearGradient + id="linearGradient4102" + osb:paint="solid"><stop + style="stop-color:#000000;stop-opacity:1;" + offset="0" + id="stop4104" /></linearGradient><linearGradient + id="linearGradient4092" + osb:paint="solid"><stop + style="stop-color:#000000;stop-opacity:1;" + offset="0" + id="stop4094" /></linearGradient><linearGradient + id="linearGradient5397" + osb:paint="solid"><stop + style="stop-color:#000000;stop-opacity:1;" + offset="0" + id="stop5399" /></linearGradient><linearGradient + id="linearGradient5389" + osb:paint="solid"><stop + style="stop-color:#000000;stop-opacity:1;" + offset="0" + id="stop5391" /></linearGradient><linearGradient + id="linearGradient3947" + osb:paint="solid"><stop + style="stop-color:#000000;stop-opacity:1;" + offset="0" + id="stop3949" /></linearGradient><linearGradient + id="linearGradient3940" + osb:paint="solid"><stop + style="stop-color:#ffffff;stop-opacity:1;" + offset="0" + id="stop3942" /></linearGradient><linearGradient + id="linearGradient4074" + osb:paint="solid"><stop + style="stop-color:#000000;stop-opacity:1;" + offset="0" + id="stop4076" /></linearGradient><linearGradient + id="linearGradient5199" + osb:paint="solid"><stop + style="stop-color:#000000;stop-opacity:1;" + offset="0" + id="stop5201" /></linearGradient><marker + style="overflow:visible" + inkscape:stockid="InfiniteLineStart" + id="InfiniteLineStart" + refX="0" + refY="0" + orient="auto"><g + id="g4623" + transform="translate(-13,0)"><circle + d="M 3.8,0 C 3.8,0.44182781 3.4418278,0.80000001 3,0.80000001 2.5581722,0.80000001 2.2,0.44182781 2.2,0 c 0,-0.44182781 0.3581722,-0.80000001 0.8,-0.80000001 0.4418278,0 0.8,0.3581722 0.8,0.80000001 z" + id="circle4625" + r="0.80000001" + cy="0" + cx="3" + sodipodi:cx="3" + sodipodi:cy="0" + sodipodi:rx="0.80000001" + sodipodi:ry="0.80000001" /><circle + d="M 7.3,0 C 7.3,0.44182781 6.9418278,0.80000001 6.5,0.80000001 6.0581722,0.80000001 5.7,0.44182781 5.7,0 c 0,-0.44182781 0.3581722,-0.80000001 0.8,-0.80000001 0.4418278,0 0.8,0.3581722 0.8,0.80000001 z" + id="circle4627" + r="0.80000001" + cy="0" + cx="6.5" + sodipodi:cx="6.5" + sodipodi:cy="0" + sodipodi:rx="0.80000001" + sodipodi:ry="0.80000001" /><circle + d="M 10.8,0 C 10.8,0.44182781 10.441828,0.80000001 10,0.80000001 9.5581722,0.80000001 9.2,0.44182781 9.2,0 c 0,-0.44182781 0.3581722,-0.80000001 0.8,-0.80000001 0.441828,0 0.8,0.3581722 0.8,0.80000001 z" + id="circle4629" + r="0.80000001" + cy="0" + cx="10" + sodipodi:cx="10" + sodipodi:cy="0" + sodipodi:rx="0.80000001" + sodipodi:ry="0.80000001" /></g></marker><linearGradient + id="linearGradient6082" + osb:paint="solid"><stop + style="stop-color:#19001d;stop-opacity:1;" + offset="0" + id="stop6084" /></linearGradient><linearGradient + id="linearGradient4624" + osb:paint="gradient"><stop + style="stop-color:#000000;stop-opacity:1;" + offset="0" + id="stop4626" /><stop + style="stop-color:#000000;stop-opacity:0;" + offset="1" + id="stop4628" /></linearGradient><linearGradient + id="linearGradient3884" + osb:paint="solid"><stop + style="stop-color:#ff00ff;stop-opacity:0.80888891;" + offset="0" + id="stop3886" /></linearGradient><linearGradient + id="linearGradient3999" + osb:paint="solid"><stop + style="stop-color:#df0000;stop-opacity:1;" + offset="0" + id="stop4001" /></linearGradient><linearGradient + id="linearGradient3993" + osb:paint="solid"><stop + style="stop-color:#e81013;stop-opacity:1;" + offset="0" + id="stop3995" /></linearGradient><linearGradient + id="linearGradient3987" + osb:paint="solid"><stop + style="stop-color:#1100aa;stop-opacity:1;" + offset="0" + id="stop3989" /></linearGradient><clipPath + clipPathUnits="userSpaceOnUse" + id="clipPath3020"><path + d="m 0,0 595.27557,0 0,841.88977 L 0,841.88977 0,0 z" + id="path3022" + inkscape:connector-curvature="0" /></clipPath><linearGradient + x1="244.67969" + y1="91.625" + x2="282.85547" + y2="94.738281" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.8,0,0.30245,-0.740624,0,841.88977)" + spreadMethod="pad" + id="linearGradient3024"><stop + style="stop-opacity:1;stop-color:#ffffff" + offset="0" + id="stop3026" /><stop + style="stop-opacity:0;stop-color:#ffffff" + offset="1" + id="stop3028" /></linearGradient><mask + maskUnits="userSpaceOnUse" + x="0" + y="0" + width="1" + height="1" + id="mask3030"><g + id="g3032"><g + clip-path="url(#clipPath3020)" + id="g3034"><g + id="g3036"><path + d="m 0,0 595.27557,0 0,841.88977 L 0,841.88977 0,0 z" + style="fill:url(#linearGradient3024);fill-opacity:1;fill-rule:nonzero;stroke:none" + id="path3038" + inkscape:connector-curvature="0" /></g></g></g></mask><clipPath + clipPathUnits="userSpaceOnUse" + id="clipPath3044"><path + d="m 0,0 595.27557,0 0,841.88977 L 0,841.88977 0,0 z" + id="path3046" + inkscape:connector-curvature="0" /></clipPath><linearGradient + x1="244.67969" + y1="91.625" + x2="282.85547" + y2="94.738281" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.8,0,0.30245,-0.740624,0,841.88977)" + spreadMethod="pad" + id="linearGradient3048"><stop + style="stop-opacity:1;stop-color:#ffffff" + offset="0" + id="stop3050" /><stop + style="stop-opacity:1;stop-color:#ffffff" + offset="1" + id="stop3052" /></linearGradient> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +<linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient3925" + gradientUnits="userSpaceOnUse" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient3994" + gradientUnits="userSpaceOnUse" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +<linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient3215" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.5802469,0,0,1.5802469,-76.377829,-420.16955)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient3277" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.5802469,0,0,1.5802469,-76.377829,-420.16955)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +<linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient5571" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(205.04392,118.40148)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient5573" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(205.04392,118.40148)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient5846" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(205.04392,118.40148)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient5848" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(205.04392,118.40148)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient5984" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(205.04392,118.40148)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient5986" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(205.04392,118.40148)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +<linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient3223" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(205.91759,116.92956)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient3258" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(205.91759,116.92956)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient5397" + id="linearGradient5401" + x1="220.33125" + y1="842.125" + x2="647.23126" + y2="842.125" + gradientUnits="userSpaceOnUse" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient6110" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(205.91759,116.92956)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient6112" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(205.91759,116.92956)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient6230" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(192.69259,-171.17041)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient6232" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(192.69259,-171.17041)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +<linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient3242" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(192.81135,-171.26503)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient3278" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(192.81135,-171.26503)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient6968" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(192.81135,-171.26503)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient6983" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(192.81135,-171.26503)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /> + + + + + + + + + + + + + + + + + +<linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient3206" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(192.81135,-171.26503)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient3221" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(192.81135,-171.26503)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /> + + + + + + + + + + + + + + + + + +<linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient3208" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(192.81135,-171.26503)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient3224" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(192.81135,-171.26503)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient3237" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(192.81135,-171.26503)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient3239" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(192.81135,-171.26503)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient3395" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(192.81135,-171.26503)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient3397" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(192.81135,-171.26503)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +<linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient9966" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(192.81135,-171.26503)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient9985" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(192.81135,-171.26503)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient10030" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(192.81135,-171.26503)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient10041" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(192.81135,-171.26503)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient10068" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(192.81135,-171.26503)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient10087" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(192.81135,-171.26503)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient10132" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(192.81135,-171.26503)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient10143" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(192.81135,-171.26503)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient10789" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(186.01135,-187.66503)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient10791" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(186.01135,-187.66503)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient10793" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(186.01135,-187.66503)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient10795" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(186.01135,-187.66503)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient10797" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(186.01135,-187.66503)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient10799" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(186.01135,-187.66503)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient10801" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(186.01135,-187.66503)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient10803" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(186.01135,-187.66503)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient12409" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(192.81135,-171.26503)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient12411" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(192.81135,-171.26503)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient12413" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(192.81135,-171.26503)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient12415" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(192.81135,-171.26503)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient12417" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(192.81135,-171.26503)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient12419" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(192.81135,-171.26503)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient12421" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(192.81135,-171.26503)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient12423" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(192.81135,-171.26503)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient13457" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(186.01135,-187.66503)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient13459" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(186.01135,-187.66503)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient13461" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(186.01135,-187.66503)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient13463" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(186.01135,-187.66503)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient13465" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(186.01135,-187.66503)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient13467" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(186.01135,-187.66503)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient13469" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(186.01135,-187.66503)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient13471" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(186.01135,-187.66503)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient33404" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient33417" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient33454" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient33465" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient33486" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient33499" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient33536" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient33547" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient33567" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient33581" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient33617" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient33628" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient33650" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient33664" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient33701" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient33712" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient33735" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient33750" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient33787" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient33798" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient33821" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient33836" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient33873" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient33884" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient33906" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient33920" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient33957" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient33968" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient33990" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient34004" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient34041" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient34052" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient34075" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient34090" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient34127" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient34138" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient34161" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient34176" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient34213" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient34224" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient34246" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient34260" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient34297" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient34308" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient34330" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient34344" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient34381" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient34392" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient34415" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient34430" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient34467" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient34478" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient34501" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient34516" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient34553" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient34564" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient34586" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient34600" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient34637" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient34648" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient34670" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient34684" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient34721" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient34732" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient34752" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient34766" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient34802" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient34813" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient34835" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient34849" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient34886" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient34897" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient34917" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient34931" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient34967" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient34978" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient35000" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient35014" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient35051" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient35062" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient35085" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient35100" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient35137" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient35148" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient35171" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient35186" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient35223" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient35234" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient35256" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient35270" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient35307" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient35318" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient35340" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient35354" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient35391" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient35402" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient35425" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient35440" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient35477" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient35488" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient35511" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient35526" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient35563" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient35574" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient35596" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient35610" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient35647" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient35658" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient35680" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient35694" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient35731" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient35742" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient35765" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient35780" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient35817" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient35828" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient35851" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient35866" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient35903" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient35914" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient35936" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient35950" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient35987" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient35998" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient36020" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient36034" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient36071" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient36082" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(121.21135,-106.93097)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +<linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient6236" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient6249" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient6286" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient6297" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient6318" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient6331" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient6368" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient6379" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient6399" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient6413" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient6449" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient6460" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient6482" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient6496" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient6533" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient6544" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient6567" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient6582" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient6619" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient6630" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient6653" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient6668" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient6705" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient6716" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient6738" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient6752" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient6789" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient6800" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient6822" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient6836" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient6873" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient6884" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient6907" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient6922" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient6959" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient6970" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient6993" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient7008" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient7045" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient7056" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient7078" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient7092" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient7129" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient7140" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient7162" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient7176" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient7213" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient7224" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient7247" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient7262" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient7299" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient7310" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient7333" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient7348" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient7385" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient7396" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient7418" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient7432" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient7469" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient7480" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient7502" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient7516" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient7553" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient7564" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient7584" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient7598" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient7634" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient7645" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient7667" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient7681" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient7718" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient7729" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient7749" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient7763" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient7799" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient7810" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient7832" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient7846" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient7883" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient7894" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient7917" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient7932" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient7969" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient7980" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient8003" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient8018" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient8055" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient8066" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient8088" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient8102" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient8139" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient8150" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient8172" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient8186" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient8223" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient8234" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient8257" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient8272" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient8309" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient8320" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient8343" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient8358" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient8395" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient8406" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient8428" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient8442" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient8479" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient8490" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient8512" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient8526" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient8563" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient8574" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient8597" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient8612" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient8649" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient8660" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient8683" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient8698" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient8735" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient8746" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient8768" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient8782" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient8819" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient8830" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient8852" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient8866" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient8903" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient8914" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.86461,328.26889)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +<linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3999" + id="linearGradient7047" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.73127,327.86885)" + x1="275.05582" + y1="662.03979" + x2="433.45126" + y2="662.03979" /><linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient19060" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(245.71875,327.86029)" + x1="244.285" + y1="699.48529" + x2="280.11301" + y2="699.48529" /> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +</defs><sodipodi:namedview + pagecolor="#ffffff" + bordercolor="#666666" + borderopacity="1" + objecttolerance="10" + gridtolerance="10" + guidetolerance="10" + inkscape:pageopacity="1" + inkscape:pageshadow="2" + inkscape:window-width="1430" + inkscape:window-height="845" + id="namedview3006" + showgrid="false" + inkscape:zoom="1" + inkscape:cx="594.81919" + inkscape:cy="314.63564" + inkscape:window-x="0" + inkscape:window-y="0" + inkscape:window-maximized="0" + inkscape:current-layer="g3012" + inkscape:snap-grids="true" + fit-margin-top="0" + fit-margin-left="0" + fit-margin-right="0" + fit-margin-bottom="0" + showborder="true" + inkscape:showpageshadow="true" + showguides="true" + inkscape:guide-bbox="true" + inkscape:snap-global="false" + inkscape:snap-bbox="true" + inkscape:snap-midpoints="true" + inkscape:snap-to-guides="false"><inkscape:grid + type="xygrid" + id="grid3199" + empspacing="5" + visible="true" + enabled="true" + snapvisiblegridlinesonly="true" /></sodipodi:namedview><g + id="g3012" + inkscape:groupmode="layer" + inkscape:label="FAC" + transform="matrix(1.25,0,0,-1.25,-362.65613,1967.5048)" + style="display:inline"> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +<g + id="g3595"><rect + transform="scale(1,-1)" + y="-1573.2125" + x="290.92581" + height="509.8042" + width="793.49268" + id="rect4555" + style="fill:none;stroke:#000000;stroke-width:1.5999999;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" /><rect + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.24000007;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" + id="rect4409" + width="3.9061351" + height="31.520151" + x="520.16711" + y="-1213.8158" + transform="scale(1,-1)" /><rect + style="fill:#0000ff;fill-opacity:1;fill-rule:evenodd;stroke:#0000ff;stroke-width:0.24000007;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" + id="rect4401" + width="3.9061351" + height="43.168903" + x="656.31409" + y="-1334.413" + transform="scale(1,-1)" /><rect + transform="scale(1,-1)" + y="-1334.413" + x="520.16711" + height="43.168903" + width="3.9061351" + id="rect4309" + style="fill:#0000ff;fill-opacity:1;fill-rule:evenodd;stroke:#0000ff;stroke-width:0.24000007;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" /><rect + transform="scale(1,-1)" + y="-1334.413" + x="824.08881" + height="43.168903" + width="3.9061351" + id="rect4403" + style="fill:#0000ff;fill-opacity:1;fill-rule:evenodd;stroke:#0000ff;stroke-width:0.24000007;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" /><rect + transform="scale(1,-1)" + y="-1232.4293" + x="563.03278" + height="13.361802" + width="14.281804" + id="rect4213" + style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.24000001;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" /><rect + inkscape:transform-center-x="-1.0614676" + inkscape:transform-center-y="-4.5514651" + transform="matrix(0.74553647,-0.66646483,0,1,0,0)" + y="1736.2219" + x="769.74976" + height="62.666431" + width="4.5189481" + id="rect3404" + style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.27795643;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" /><rect + style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.29507753;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" + id="rect4211" + width="4.7647319" + height="105.52592" + x="-1847.5461" + y="-1958.416" + transform="matrix(0.74991829,-0.66153047,-1,0,0,0)" + inkscape:transform-center-y="1.0612804" + inkscape:transform-center-x="7.6443688" /><rect + transform="scale(1,-1)" + y="-1285.8766" + x="467.43427" + height="63.497108" + width="106.44215" + id="rect3398" + style="fill:#ffff00;fill-opacity:1;fill-rule:evenodd;stroke:#060000;stroke-width:0.24000001;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" /><rect + style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.24000001;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" + id="rect4239" + width="14.281804" + height="13.361802" + x="699.17926" + y="-1232.4293" + transform="scale(1,-1)" /><rect + style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.27795643;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" + id="rect4241" + width="4.5189481" + height="62.666431" + x="952.36511" + y="1857.9291" + transform="matrix(0.74553647,-0.66646483,0,1,0,0)" + inkscape:transform-center-y="-4.5517162" + inkscape:transform-center-x="-1.061456" /><rect + inkscape:transform-center-x="7.6440797" + inkscape:transform-center-y="1.0612804" + transform="matrix(0.74991829,-0.66153047,-1,0,0,0)" + y="-2094.5627" + x="-1847.5461" + height="105.52592" + width="4.7647319" + id="rect4243" + style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.29507753;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" /><rect + style="fill:#ffff00;fill-opacity:1;fill-rule:evenodd;stroke:#060000;stroke-width:0.24000001;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" + id="rect4245" + width="106.44215" + height="63.497108" + x="603.58069" + y="-1285.8766" + transform="scale(1,-1)" /><rect + transform="scale(1,-1)" + y="-1231.0588" + x="869.15442" + height="13.361802" + width="14.281804" + id="rect4259" + style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.24000001;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" /><rect + inkscape:transform-center-x="-1.0614356" + inkscape:transform-center-y="-4.5516985" + transform="matrix(0.74553647,-0.66646483,0,1,0,0)" + y="2008.506" + x="1180.3541" + height="62.666431" + width="4.5189481" + id="rect4261" + style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.27795643;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" /><rect + style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.29507753;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" + id="rect4263" + width="4.7647319" + height="105.52592" + x="-1845.4745" + y="-2262.9836" + transform="matrix(0.74991829,-0.66153047,-1,0,0,0)" + inkscape:transform-center-y="1.0611998" + inkscape:transform-center-x="7.6439322" /><rect + transform="scale(1,-1)" + y="-1284.5061" + x="773.55615" + height="63.497108" + width="106.44215" + id="rect4265" + style="fill:#ffff00;fill-opacity:1;fill-rule:evenodd;stroke:#060000;stroke-width:0.24000001;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" /><rect + style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.24000001;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" + id="rect4269" + width="14.281804" + height="13.361802" + x="562.30048" + y="-1123.4791" + transform="scale(1,-1)" /><rect + style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.27795643;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" + id="rect4271" + width="4.5189481" + height="62.666431" + x="768.76746" + y="1626.6176" + transform="matrix(0.74553647,-0.66646483,0,1,0,0)" + inkscape:transform-center-y="-4.5517903" + inkscape:transform-center-x="-1.0614992" /><rect + inkscape:transform-center-x="7.6443472" + inkscape:transform-center-y="1.0612278" + transform="matrix(0.74991829,-0.66153047,-1,0,0,0)" + y="-1834.1765" + x="-1682.8523" + height="105.52592" + width="4.7647319" + id="rect4273" + style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.29507753;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" /><rect + style="fill:#ff00ff;fill-opacity:1;fill-rule:evenodd;stroke:#060000;stroke-width:0.24000001;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" + id="rect4275" + width="106.44215" + height="63.497108" + x="466.70187" + y="-1176.9263" + transform="scale(1,-1)" /><rect + transform="scale(1,-1)" + y="-1123.4791" + x="698.4469" + height="13.361802" + width="14.281804" + id="rect4279" + style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.24000001;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" /><rect + inkscape:transform-center-x="-1.0614529" + inkscape:transform-center-y="-4.5517507" + transform="matrix(0.74553647,-0.66646483,0,1,0,0)" + y="1748.324" + x="951.38263" + height="62.666431" + width="4.5189481" + id="rect4281" + style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.27795643;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" /><rect + style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.29507753;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" + id="rect4283" + width="4.7647319" + height="105.52592" + x="-1682.8523" + y="-1970.323" + transform="matrix(0.74991829,-0.66153047,-1,0,0,0)" + inkscape:transform-center-y="1.0612278" + inkscape:transform-center-x="7.644363" /><rect + transform="scale(1,-1)" + y="-1176.9263" + x="602.84839" + height="63.497108" + width="106.44215" + id="rect4285" + style="fill:#ff00ff;fill-opacity:1;fill-rule:evenodd;stroke:#060000;stroke-width:0.24000001;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" /><rect + style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.24000001;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" + id="rect4289" + width="14.281804" + height="13.361802" + x="868.42206" + y="-1122.1088" + transform="scale(1,-1)" /><rect + style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.27795643;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" + id="rect4291" + width="4.5189481" + height="62.666431" + x="1179.3717" + y="1898.9011" + transform="matrix(0.74553647,-0.66646483,0,1,0,0)" + inkscape:transform-center-y="-4.5515741" + inkscape:transform-center-x="-1.0614391" /><rect + inkscape:transform-center-x="7.6441539" + inkscape:transform-center-y="1.0611978" + transform="matrix(0.74991829,-0.66153047,-1,0,0,0)" + y="-2138.7451" + x="-1680.7808" + height="105.52592" + width="4.7647319" + id="rect4293" + style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.29507753;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" /><rect + style="fill:#ff00ff;fill-opacity:1;fill-rule:evenodd;stroke:#060000;stroke-width:0.24000001;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" + id="rect4295" + width="106.44215" + height="63.497108" + x="772.82373" + y="-1175.5558" + transform="scale(1,-1)" /><rect + style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.24000001;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" + id="rect4299" + width="14.281804" + height="13.361802" + x="759.31616" + y="-1416.7537" + transform="scale(1,-1)" /><rect + style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.27795643;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" + id="rect4301" + width="4.5189481" + height="62.666431" + x="1033.0277" + y="2096.0117" + transform="matrix(0.74553647,-0.66646483,0,1,0,0)" + inkscape:transform-center-y="-4.5513687" + inkscape:transform-center-x="-1.0615848" /><rect + inkscape:transform-center-x="7.6445137" + inkscape:transform-center-y="1.0610954" + transform="matrix(0.74991829,-0.66153047,-1,0,0,0)" + y="-2363.6514" + x="-2126.1794" + height="105.52592" + width="4.7647319" + id="rect4303" + style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.29507753;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" /><rect + style="fill:#00ffff;fill-opacity:1;fill-rule:evenodd;stroke:#060000;stroke-width:0.24000001;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" + id="rect4305" + width="106.44215" + height="63.497108" + x="663.71747" + y="-1470.2007" + transform="scale(1,-1)" /><rect + transform="scale(1,-1)" + y="-1347.775" + x="443.26501" + height="5.6478796" + width="603.90399" + id="rect4307" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.24000007;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" /><rect + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.24000007;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" + id="rect4405" + width="3.9061351" + height="29.807098" + x="824.08881" + y="-1213.8158" + transform="scale(1,-1)" /><rect + transform="scale(1,-1)" + y="-1213.8158" + x="656.31409" + height="31.520151" + width="3.9061351" + id="rect4407" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.24000007;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" /><rect + style="fill:#0000ff;fill-opacity:1;fill-rule:evenodd;stroke:#0000ff;stroke-width:0.24000007;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" + id="rect4399" + width="3.9061351" + height="43.168903" + x="716.77637" + y="-1397.4531" + transform="scale(1,-1)" /><path + style="fill:#f90000;fill-opacity:1;stroke:#ff0000;stroke-width:0.80000013px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" + d="m 434.78142,1344.9108 c 17.05113,-6.9179 16.7232,-7.0718 16.7232,-7.0718 l -2.13136,6.7645 2.13136,7.2254 z" + id="path4397" + inkscape:connector-curvature="0" + sodipodi:nodetypes="ccccc" /><path + sodipodi:nodetypes="ccccc" + inkscape:connector-curvature="0" + id="path4411" + d="m 1059.8206,1344.9108 c -17.0511,-6.9179 -16.7231,-7.0718 -16.7231,-7.0718 l 2.1314,6.7645 -2.1314,7.2254 z" + style="fill:#f90000;fill-opacity:1;stroke:#ff0000;stroke-width:0.80000013px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" /><path + style="fill:#0000ff;fill-opacity:1;stroke:#0000ff;stroke-width:0.80000013px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" + d="m 825.84815,1341.2369 c -4.37631,-9.6651 -4.47357,-9.479 -4.47357,-9.479 l 4.27909,1.208 4.57077,-1.208 z" + id="path4413" + inkscape:connector-curvature="0" + sodipodi:nodetypes="ccccc" /><path + sodipodi:nodetypes="ccccc" + inkscape:connector-curvature="0" + id="path4415" + d="m 658.07127,1341.2369 c -4.37629,-9.6651 -4.47356,-9.479 -4.47356,-9.479 l 4.27911,1.208 4.57074,-1.208 z" + style="fill:#0000ff;fill-opacity:1;stroke:#0000ff;stroke-width:0.80000013px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" /><path + style="fill:#0000ff;fill-opacity:1;stroke:#0000ff;stroke-width:0.80000013px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" + d="m 521.92496,1341.2369 c -4.37633,-9.6651 -4.47358,-9.479 -4.47358,-9.479 l 4.27908,1.208 4.57077,-1.208 z" + id="path4417" + inkscape:connector-curvature="0" + sodipodi:nodetypes="ccccc" /><path + sodipodi:nodetypes="ccccc" + inkscape:connector-curvature="0" + id="path4419" + d="m 521.92496,1287.9034 c -4.37633,9.665 -4.47358,9.479 -4.47358,9.479 l 4.27908,-1.208 4.57077,1.208 z" + style="fill:#0000ff;fill-opacity:1;stroke:#0000ff;stroke-width:0.80000013px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" /><path + style="fill:#0000ff;fill-opacity:1;stroke:#0000ff;stroke-width:0.80000013px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" + d="m 658.07127,1287.9034 c -4.37629,9.665 -4.47356,9.479 -4.47356,9.479 l 4.27911,-1.208 4.57074,1.208 z" + id="path4421" + inkscape:connector-curvature="0" + sodipodi:nodetypes="ccccc" /><path + sodipodi:nodetypes="ccccc" + inkscape:connector-curvature="0" + id="path4423" + d="m 825.84815,1287.9034 c -4.37631,9.665 -4.47357,9.479 -4.47357,9.479 l 4.27909,-1.208 4.57077,1.208 z" + style="fill:#0000ff;fill-opacity:1;stroke:#0000ff;stroke-width:0.80000013px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" /><path + style="fill:#f90000;fill-opacity:1;stroke:#ff0000;stroke-width:0.80000013px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" + d="m 825.84815,1177.5829 c -4.37631,9.6648 -4.47357,9.479 -4.47357,9.479 l 4.27909,-1.2082 4.57077,1.2082 z" + id="path4425" + inkscape:connector-curvature="0" + sodipodi:nodetypes="ccccc" /><path + sodipodi:nodetypes="ccccc" + inkscape:connector-curvature="0" + id="path4429" + d="m 658.07127,1178.2681 c -4.37629,9.6649 -4.47356,9.479 -4.47356,9.479 l 4.27911,-1.2082 4.57074,1.2082 z" + style="fill:#f90000;fill-opacity:1;stroke:#ff0000;stroke-width:0.80000013px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" /><path + style="fill:#f90000;fill-opacity:1;stroke:#ff0000;stroke-width:0.80000013px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" + d="m 521.92496,1178.2681 c -4.37633,9.6649 -4.47358,9.479 -4.47358,9.479 l 4.27908,-1.2082 4.57077,1.2082 z" + id="path4431" + inkscape:connector-curvature="0" + sodipodi:nodetypes="ccccc" /><path + sodipodi:nodetypes="ccccc" + inkscape:connector-curvature="0" + id="path4433" + d="m 825.84815,1216.5264 c -4.37631,-9.6647 -4.47357,-9.4788 -4.47357,-9.4788 l 4.27909,1.2081 4.57077,-1.2081 z" + style="fill:#f90000;fill-opacity:1;stroke:#ff0000;stroke-width:0.80000013px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" /><path + style="fill:#f90000;fill-opacity:1;stroke:#ff0000;stroke-width:0.80000013px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" + d="m 658.3551,1217.9214 c -4.37631,-9.6651 -4.47357,-9.479 -4.47357,-9.479 l 4.27911,1.2079 4.57074,-1.2079 z" + id="path4435" + inkscape:connector-curvature="0" + sodipodi:nodetypes="ccccc" /><path + sodipodi:nodetypes="ccccc" + inkscape:connector-curvature="0" + id="path4437" + d="m 521.92496,1217.2118 c -4.37633,-9.6651 -4.47358,-9.4788 -4.47358,-9.4788 l 4.27908,1.2078 4.57077,-1.2078 z" + style="fill:#f90000;fill-opacity:1;stroke:#ff0000;stroke-width:0.80000013px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" /><path + style="fill:#0000ff;fill-opacity:1;stroke:#0000ff;stroke-width:0.80000013px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" + d="m 718.57441,1401.8788 c -4.3763,-9.665 -4.47357,-9.479 -4.47357,-9.479 l 4.27909,1.208 4.57077,-1.208 z" + id="path4439" + inkscape:connector-curvature="0" + sodipodi:nodetypes="ccccc" /><path + sodipodi:nodetypes="ccccc" + inkscape:connector-curvature="0" + id="path4441" + d="m 718.57441,1349.5732 c -4.3763,9.6649 -4.47357,9.4791 -4.47357,9.4791 l 4.27909,-1.2079 4.57077,1.2079 z" + style="fill:#0000ff;fill-opacity:1;stroke:#0000ff;stroke-width:0.80000013px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" /><text + transform="scale(1.0338535,-0.96725508)" + sodipodi:linespacing="125%" + id="text4443" + y="-1572.6313" + x="355.07458" + style="font-size:25.50304031px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans;-inkscape-font-specification:Sans Bold" + xml:space="preserve"><tspan + y="-1572.6313" + x="355.07458" + id="tspan4445" + sodipodi:role="line">SMP - Symmetric Multiprocessor System</tspan></text> +<text + transform="scale(1.0338535,-0.96725508)" + sodipodi:linespacing="125%" + id="text4447" + y="-1401.1943" + x="457.08701" + style="font-size:17.00202751px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans;-inkscape-font-specification:Sans" + xml:space="preserve"><tspan + y="-1401.1943" + x="457.08701" + id="tspan4449" + sodipodi:role="line">System Bus</tspan></text> +<text + transform="scale(1.0338535,-0.96725508)" + sodipodi:linespacing="125%" + id="text4451" + y="-1289.2528" + x="476.4505" + style="font-size:17.00202751px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans;-inkscape-font-specification:Sans" + xml:space="preserve"><tspan + y="-1289.2528" + x="476.4505" + id="tspan4453" + sodipodi:role="line">Cache</tspan></text> +<text + xml:space="preserve" + style="font-size:17.00202751px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans;-inkscape-font-specification:Sans" + x="608.61133" + y="-1289.2528" + id="text4455" + sodipodi:linespacing="125%" + transform="scale(1.0338535,-0.96725508)"><tspan + sodipodi:role="line" + id="tspan4457" + x="608.61133" + y="-1289.2528">Cache</tspan></text> +<text + transform="scale(1.0338535,-0.96725508)" + sodipodi:linespacing="125%" + id="text4459" + y="-1289.7251" + x="772.30676" + style="font-size:17.00202751px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans;-inkscape-font-specification:Sans" + xml:space="preserve"><tspan + y="-1289.7251" + x="772.30676" + id="tspan4461" + sodipodi:role="line">Cache</tspan></text> +<text + transform="scale(1.0338535,-0.96725508)" + sodipodi:linespacing="125%" + id="text4463" + y="-1182.5293" + x="503.3703" + style="font-size:17.00202751px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans;-inkscape-font-specification:Sans" + xml:space="preserve"><tspan + y="-1182.5293" + x="503.3703" + id="tspan4465" + sodipodi:role="line">Processor</tspan><tspan + id="tspan4467" + y="-1161.2767" + x="503.3703" + sodipodi:role="line">1</tspan></text> +<text + xml:space="preserve" + style="font-size:17.00202751px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans;-inkscape-font-specification:Sans" + x="635.05878" + y="-1182.5293" + id="text4469" + sodipodi:linespacing="125%" + transform="scale(1.0338535,-0.96725508)"><tspan + sodipodi:role="line" + id="tspan4471" + x="635.05878" + y="-1182.5293">Processor</tspan><tspan + sodipodi:role="line" + x="635.05878" + y="-1161.2767" + id="tspan4473">2</tspan></text> +<text + transform="scale(1.0338535,-0.96725508)" + sodipodi:linespacing="125%" + id="text4475" + y="-1182.5293" + x="799.22614" + style="font-size:17.00202751px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans;-inkscape-font-specification:Sans" + xml:space="preserve"><tspan + y="-1182.5293" + x="799.22614" + id="tspan4477" + sodipodi:role="line">Processor</tspan><tspan + id="tspan4479" + y="-1161.2767" + x="799.22614" + sodipodi:role="line">n</tspan></text> +<text + transform="scale(1.0338535,-0.96725508)" + sodipodi:linespacing="125%" + id="text4481" + y="-1492.8164" + x="694.17078" + style="font-size:17.00202751px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans;-inkscape-font-specification:Sans" + xml:space="preserve"><tspan + y="-1492.8164" + x="694.17078" + id="tspan4483" + sodipodi:role="line">Main</tspan><tspan + id="tspan4485" + y="-1471.5638" + x="694.17078" + sodipodi:role="line">Memory</tspan></text> +<path + sodipodi:end="6.274571" + sodipodi:start="0" + transform="matrix(1.1596337,0,0,-1.0849327,853.74868,1491.4046)" + d="m -104,271.33334 c 0,1.10457 -0.89543,2 -2,2 -1.10457,0 -2,-0.89543 -2,-2 0,-1.10457 0.89543,-2 2,-2 1.09785,0 1.99047,0.88497 1.99993,1.98278 L -106,271.33334 z" + sodipodi:ry="2" + sodipodi:rx="2" + sodipodi:cy="271.33334" + sodipodi:cx="-106" + id="path4487" + style="fill:#00000b;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.21396828;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" + sodipodi:type="arc" /><path + sodipodi:type="arc" + style="fill:#00000b;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.21396828;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" + id="path4509" + sodipodi:cx="-106" + sodipodi:cy="271.33334" + sodipodi:rx="2" + sodipodi:ry="2" + d="m -104,271.33334 c 0,1.10457 -0.89543,2 -2,2 -1.10457,0 -2,-0.89543 -2,-2 0,-1.10457 0.89543,-2 2,-2 1.09785,0 1.99047,0.88497 1.99993,1.98278 L -106,271.33334 z" + transform="matrix(1.1596337,0,0,-1.0849327,866.56669,1491.4046)" + sodipodi:start="0" + sodipodi:end="6.274571" /><path + sodipodi:end="6.274571" + sodipodi:start="0" + transform="matrix(1.1596337,0,0,-1.0849327,880.11509,1491.4046)" + d="m -104,271.33334 c 0,1.10457 -0.89543,2 -2,2 -1.10457,0 -2,-0.89543 -2,-2 0,-1.10457 0.89543,-2 2,-2 1.09785,0 1.99047,0.88497 1.99993,1.98278 L -106,271.33334 z" + sodipodi:ry="2" + sodipodi:rx="2" + sodipodi:cy="271.33334" + sodipodi:cx="-106" + id="path4511" + style="fill:#00000b;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.21396828;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" + sodipodi:type="arc" /><path + sodipodi:type="arc" + style="fill:#00000b;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.21396828;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" + id="path4523" + sodipodi:cx="-106" + sodipodi:cy="271.33334" + sodipodi:rx="2" + sodipodi:ry="2" + d="m -104,271.33334 c 0,1.10457 -0.89543,2 -2,2 -1.10457,0 -2,-0.89543 -2,-2 0,-1.10457 0.89543,-2 2,-2 1.09785,0 1.99047,0.88497 1.99993,1.98278 L -106,271.33334 z" + transform="matrix(1.1596337,0,0,-1.0849327,853.74868,1491.4046)" + sodipodi:start="0" + sodipodi:end="6.274571" /><path + sodipodi:end="6.274571" + sodipodi:start="0" + transform="matrix(1.1596337,0,0,-1.0849327,866.56669,1491.4046)" + d="m -104,271.33334 c 0,1.10457 -0.89543,2 -2,2 -1.10457,0 -2,-0.89543 -2,-2 0,-1.10457 0.89543,-2 2,-2 1.09785,0 1.99047,0.88497 1.99993,1.98278 L -106,271.33334 z" + sodipodi:ry="2" + sodipodi:rx="2" + sodipodi:cy="271.33334" + sodipodi:cx="-106" + id="path4525" + style="fill:#00000b;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.21396828;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" + sodipodi:type="arc" /><path + sodipodi:type="arc" + style="fill:#00000b;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.21396828;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" + id="path4527" + sodipodi:cx="-106" + sodipodi:cy="271.33334" + sodipodi:rx="2" + sodipodi:ry="2" + d="m -104,271.33334 c 0,1.10457 -0.89543,2 -2,2 -1.10457,0 -2,-0.89543 -2,-2 0,-1.10457 0.89543,-2 2,-2 1.09785,0 1.99047,0.88497 1.99993,1.98278 L -106,271.33334 z" + transform="matrix(1.1596337,0,0,-1.0849327,880.11509,1491.4046)" + sodipodi:start="0" + sodipodi:end="6.274571" /><text + transform="scale(1.0338535,-0.96725504)" + sodipodi:linespacing="125%" + id="text4557" + y="-1107.2344" + x="935.65778" + style="font-size:7.76896px;font-style:italic;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Times New Roman;-inkscape-font-specification:'Times New Roman, Bold Italic'" + xml:space="preserve"><tspan + y="-1107.2344" + x="935.65778" + id="tspan4559" + sodipodi:role="line">By Ferruccio Zulian - Milan.Italy</tspan></text> +<rect + style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.24000001;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" + id="rect3583" + width="14.281804" + height="13.361802" + x="419.48236" + y="-1324.2487" + transform="scale(1,-1)" /><rect + style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.27795643;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" + id="rect3585" + width="4.5189481" + height="62.666431" + x="577.20325" + y="1699.7162" + transform="matrix(0.74553647,-0.66646483,0,1,0,0)" + inkscape:transform-center-y="-4.5515247" + inkscape:transform-center-x="-1.0614411" /><rect + inkscape:transform-center-x="7.6442119" + inkscape:transform-center-y="1.0612094" + transform="matrix(0.74991829,-0.66153047,-1,0,0,0)" + y="-1918.9532" + x="-1986.3447" + height="105.52592" + width="4.7647319" + id="rect3587" + style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.29507753;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" /><rect + style="fill:#00ff00;fill-opacity:1;fill-rule:evenodd;stroke:#060000;stroke-width:0.24000001;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" + id="rect3589" + width="106.44215" + height="63.497108" + x="323.88385" + y="-1377.696" + transform="scale(1,-1)" /><text + xml:space="preserve" + style="font-size:17.00202751px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans;-inkscape-font-specification:Sans" + x="365.93723" + y="-1395.527" + id="text3591" + sodipodi:linespacing="125%" + transform="scale(1.0338535,-0.96725508)"><tspan + sodipodi:role="line" + id="tspan3593" + x="365.93723" + y="-1395.527">Bus</tspan><tspan + id="tspan3595" + sodipodi:role="line" + x="365.93723" + y="-1374.2744">Arbiter</tspan></text> +<rect + style="fill:#0000ff;fill-opacity:1;fill-rule:evenodd;stroke:#0000ff;stroke-width:0.24000007;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" + id="rect3597" + width="3.9061351" + height="43.168903" + x="979.09229" + y="-1334.413" + transform="scale(1,-1)" /><rect + style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.24000001;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" + id="rect3599" + width="14.281804" + height="13.361802" + x="1024.1577" + y="-1231.0588" + transform="scale(1,-1)" /><rect + style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.27795643;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" + id="rect3601" + width="4.5189481" + height="62.666431" + x="1388.2655" + y="2147.0703" + transform="matrix(0.74553647,-0.66646483,0,1,0,0)" + inkscape:transform-center-y="-4.5518006" + inkscape:transform-center-x="-1.0615242" /><rect + inkscape:transform-center-x="7.6444516" + inkscape:transform-center-y="1.0611998" + transform="matrix(0.74991829,-0.66153047,-1,0,0,0)" + y="-2417.9919" + x="-1845.4745" + height="105.52592" + width="4.7647319" + id="rect3603" + style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.29507753;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" /><rect + style="fill:#b3b3b3;fill-opacity:1;fill-rule:evenodd;stroke:#060000;stroke-width:0.24000001;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0" + id="rect3605" + width="106.44215" + height="63.497108" + x="928.55939" + y="-1284.5061" + transform="scale(1,-1)" /><path + sodipodi:nodetypes="ccccc" + inkscape:connector-curvature="0" + id="path3617" + d="m 980.85382,1341.2369 c -4.37635,-9.6651 -4.47362,-9.479 -4.47362,-9.479 l 4.27907,1.208 4.5708,-1.208 z" + style="fill:#0000ff;fill-opacity:1;stroke:#0000ff;stroke-width:0.80000013px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" /><path + style="fill:#0000ff;fill-opacity:1;stroke:#0000ff;stroke-width:0.80000013px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" + d="m 980.85382,1287.9034 c -4.37635,9.665 -4.47362,9.479 -4.47362,9.479 l 4.27907,-1.208 4.5708,1.208 z" + id="path3619" + inkscape:connector-curvature="0" + sodipodi:nodetypes="ccccc" /><text + xml:space="preserve" + style="font-size:17.00202751px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#002b11;fill-opacity:1;stroke:none;font-family:Sans;-inkscape-font-specification:Sans" + x="937.94635" + y="-1289.7251" + id="text3625" + sodipodi:linespacing="125%" + transform="scale(1.0338535,-0.96725508)"><tspan + sodipodi:role="line" + id="tspan3627" + x="937.94635" + y="-1289.7251">I/O</tspan></text> +</g> +</g></svg>
\ No newline at end of file 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/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/smp.mdwn b/open_issues/smp.mdwn index 89474d25..b0287a48 100644 --- a/open_issues/smp.mdwn +++ b/open_issues/smp.mdwn @@ -12,36 +12,296 @@ License|/fdl]]."]]"""]] [[!tag open_issue_glibc open_issue_gnumach open_issue_hurd]] -See also the [[FAQ entry|faq/smp]]. +<!-- This paragraph is parapharisg the wikipedia page +https://en.wikipedia.org/wiki/Symmetric_multiprocessing#Advantages/Disadvantages +--> + +SMP stands for Symmetric multiprocessing, which is a computer that has numerous +identical processors connected to a single shared main memory. All processors +are controlled by one single operating system, and each processor can access all +devices. Operating systems with SMP can provide more performance, but it is not +trivial to do so. It is a little like having a packed board meeting. More +people in the room potentially means more can get done, but only one person can +speak at a time. Scheduling everyone to speak can be quite an involved task. + + + + NOTE: Many of the veteran Hurd developers consider this task too large for a Google summer of code project. + +<!-- +This svg is cc attribute +https://en.wikipedia.org/wiki/File:SMP_-_Symmetric_Multiprocessor_System.svg --> + +[[!img images/smp.svg size="700x"]] + +<!-- most of this page is taken from https://gitlab.com/snippets/1756024#solution --> + +# Current Status + + +The GNU Mach source code includes many special cases for multiprocessor, +controlled by #if NCPUS > 1 macro. + +But this support is very limited: + +- GNU Mach don't detect CPUs in runtime: The number of CPUs must be hardcoded in +compilation time. The number of cpus is set in `mach_ncpus` configuration +variable, set to 1 by default, in configfrag.ac file. This variable will +generate `NCPUS` macro, which is used by gnumach to control the special cases +for multiprocessor. If `NCPUS` > 1, then gnumach will enable multiprocessor +support, with the number of cpus set by the user in mach_ncpus +variable. Otherwise, SMP will be disabled. + +- The special cases to multicore in gnumach source code have never been tested, + so these can contain many errors. Furthermore, these special case are + incomplete: many functions, such as `cpu_number()` or `intel_startCPU()` aren't + written. + +- GNU Mach doesn't initialize the processor with the proper options for + multiprocessing. For this reason, the current support is only multithread and + not real multiprocessor support. + +- Many drivers included in Hurd aren't thread-safe, and these could crash in a + SMP environment. So, it's necessary to isolate this drivers, to avoid + concurrency problems. + + +### Solution + +To solve this, we need to implement some routines to detect the number of +processors, assign an identifier to each processor, and configure the lapic and +IPI support. These routines must be executed during Mach boot. + +> "Really, all the support you want to get from the hardware is just getting the +> number of processors, initializing them, and support for interprocessor +> interrupts (IPI) for signaling." - Samuel Thibault +> [link](https://lists.gnu.org/archive/html/bug-hurd/2018-08/msg00071.html) + +> "The process scheduler probably already has the support. What is missing is +the hardware driver for SMP: enumeration and initialization." - Samuel Thibault +[link](https://lists.gnu.org/archive/html/bug-hurd/2018-08/msg00083.html) + +The current necessary functions are `cpu_number()` (in kern/cpu_number.h) and +`intel_startCPU()`. Another non-critical function, is `cpu_control()` +[*Reference*](https://www.gnu.org/software/hurd/gnumach-doc/Processor-Control.html#Processor-Control) +Other interesting files are `pmap.c` and `sched_prim.c` We also +have to build an isolated environment to execute the non-thread-safe drivers. -# IRC, freenode, #hurd, 2012-09-30 +> "Yes, this is a real concern. For the Linux drivers, the long-term goal is to +> move them to userland anyway. For Mach drivers, quite often they are not +> performance-sensitive, so big locks would be enough." - Samuel Thibault +> [link](https://lists.gnu.org/archive/html/bug-hurd/2018-08/msg00073.html) - <braunr> i expect smp to be our next gsoc project +### Task list +1. Implement a routine to detect and identify the processors -## IRC, freenode, #hurd, 2013-01-02 + This routine must check the number of processors, initialize the lapic of BSP + (the master processor), and assign a kernel ID for each processor. This kernel + ID does not have to be equal to the APIC ID. The relation kernel/APIC can be + settled with an array, where the kernel ID is the index, and the APIC contains + the data. GNU Mach can derive the list of processors from memory, reading from + ACPI table, or from MP table. However, MP table is deprecated in most modern + CPUs, so it is preferable to use ACPI table for this. - <braunr> i'd like to mentor someone for adding smp to gnumach + The tasks to do for this are: + + - Detect the number of processors + + - Create a array indexed by kernel ID, which sets a relation with APIC ID. + + - Initialize the lapic of BSP + + - Initialize IOAPIC + This routine could be called from `i386at_init()` + (i386/i386at/model_dep.c). This function will call the functions which + initialize the lapic and the ioapic. + + **NOTE**: This routine must be executed before `intel_startCPU()` or other routines. + + - **How to find APIC table** + + To find APIC table, we can read + RSDT table [RSDT reference](http://www.uefi.org/sites/default/files/resources/ACPI%206_2_A_Sept29.pdf#G10.1358180). + To get the address of RSDT, we need to read RDSP table. We can get the + RSDP table by this [RDSP + reference](http://www.uefi.org/sites/default/files/resources/ACPI%206_2_A_Sept29.pdf#G10.1357698) + Once we have the RSDT table, we need to read *Entry* field, and search the pointer to + the APIC table in the array referenced in this field. + + We can find an example about reading ACPI table in X15 OS: + [Reference](https://github.com/richardbraun/x15/blob/0c0e2a02a42a8161e1b8dc1e1943fe5057ecb3a3/arch/x86/machine/acpi.c#L576) + + - We need to initialize the `machine_slot` of each processor (currently only initializes cpu0). + The `machine_slot` has this structure. [Reference](https://github.com/AlmuHS/GNUMach_SMP/blob/0d490ef21c156907f3f26a6cdc00842f462a877a/include/mach/machine.h#L68): + + > `struct machine_slot { /*boolean_t*/` <br/> + > `integer_t is_cpu;` <br/> + > `/* is there a cpu in this slot? */ ` <br/> + > `cpu_type_t cpu_type; /* type of cpu */` <br/> + > `cpu_subtype_t cpu_subtype; /* subtype of cpu */` <br/> + > `/*boolean_t*/ integer_t running; /* is cpu running */` <br/> + > `integer_t cpu_ticks[CPU_STATE_MAX]; integer_t` <br/> + > `clock_freq; /* clock interrupt frequency */ };` <br/> + + + We can find an example of initialization in this [link:](https://github.com/AlmuHS/GNUMach_SMP/blob/0d490ef21c156907f3f26a6cdc00842f462a877a/i386/i386at/model_dep.c#L612) + + This modification also involve the redefinition of `NCPUS`, which must be set + to the maximum **possible** number of processors. We can do this by modifying + `configfrag.ac`, with this: + + > `# Multiprocessor support is still broken.` <br/> + > `AH_TEMPLATE([MULTIPROCESSOR], [set things up for a uniprocessor])` <br/> + > `mach_ncpus=2` <br/> + > `AC_DEFINE_UNQUOTED([NCPUS], [$mach_ncpus], [number of CPUs])` </br> + > `[if [$mach_ncpus` > `-gt 1 ]; then]` <br/> + > `AC_DEFINE([MULTIPROCESSOR], [1], [set things up for a` > `multiprocessor])` + > `AC_DEFINE_UNQUOTED([NCPUS], [256], [number of CPUs]) ` <br/> + > `[fi]` <br/> + + - Interesting files and functions - `machine.c` + [Link](https://github.com/AlmuHS/GNUMach_SMP/blob/master/kern/machine.c) + - `c_boot_entry()` + [Link](https://github.com/AlmuHS/GNUMach_SMP/blob/0d490ef21c156907f3f26a6cdc00842f462a877a/i386/i386at/model_dep.c#L529) -## IRC, freenode, #hurd, 2013-03-14 + - Example, in X15 OS: + [Link](https://github.com/richardbraun/x15/blob/d6d90a3276a09da65690b019e985392bf77b53b0/arch/x86/machine/cpu.c#L1114) - <braunr> but i'm afraid we'll have to fight obscur smp-safety issues - <braunr> for one, drivers are much probably not smp safe and would require - a big kernel lock - <braunr> userspace (such as signal delivery in libc) might be affected too - <braunr> smp isn't that easy + 1.1. Implement a `cpu_number()` function. -## Richard, 2013-03-20 + This function must return the kernel ID of the processor which is executing the function. To + get this, we have to read the local apic memory space, which will show the + lapic of the current CPU. Reading the lapic, we can get its APIC ID. Once + we have the APIC ID of the current CPU, the function will search in the + Kernel/APIC array until it finds the same APIC ID. Then it will return the + index (Kernel ID) of this position. -This task actually looks too big for a GSoC project. +2. Implement a routine to initialize the processors -## IRC, freenode, #hurd, 2013-09-30 + This routine will initialize the lapic of each processor and other structures + needed to run the kernel. We can find an example of lapic initialization + here + [reference](https://github.com/mit-pdos/xv6-public/blob/b818915f793cd20c5d1e24f668534a9d690f3cc8/lapic.c#L55) + Also, we can get more information in Chapter 8.4 and 8.11 of Intel + Developer Guide, + Volume 3. [link](https://software.intel.com/sites/default/files/managed/a4/60/325384-sdm-vol-3abcd.pdf) + +3. Implement `intel_startCPU()` + + + This function will initialize the descriptor tables of the processor specified by the + parameter, and launch the startup IPI to this processor. This function will be + executed during the boot of the kernel (process 0). The task to do in this function + are: + + - Initialize the processor descriptor tables + - Launch Startup IPI to this processor + We have a current implementation of `intel_startCPU()` in this + [link](https://github.com/AlmuHS/GNUMach_SMP/blob/smp/i386/i386/mp_desc.c). + This implementation is based in XNU's `intel_startCPU()` + [function](https://github.com/nneonneo/osx-10.9-opensource/blob/f5a0b24e4d98574462c8f5e5dfcf0d37ef7e0764/xnu-2422.1.72/osfmk/i386/mp.c#L423) + + We can find explainations about how to raise an IPI in this pages: + [*Reference 1*](https://www.cs.usfca.edu/~cruse/cs630f08/lesson22.ppt), + [*Reference 2*](https://www.cheesecake.org/sac/smp.html), [*Reference + 3*](http://www.dis.uniroma1.it/pub/quaglia/AOSV-traps-interrupts.pdf) We can + get information about how to raise an IPI in Intel Developer Guide, Volume 3, + Chapter 10.6 + +4. Implement another routine to start the processors + + + This routine calls to `processor_start()` for each processor, which will start the + processor using this sequence of calls: [`processor_start(processor_t + processor)`](https://github.com/AlmuHS/GNUMach_SMP/blob/5d527f532dfba9f2da54555d5fbe585dd458579b/kern/processor.c#L447) + -> + [`cpu_start(processor->slot_num)`](https://github.com/AlmuHS/GNUMach_SMP/blob/5d527f532dfba9f2da54555d5fbe585dd458579b/i386/i386/mp_desc.c#L335) + -> + [`intel_startCPU(cpu)`](https://github.com/AlmuHS/GNUMach_SMP/blob/5d527f532dfba9f2da54555d5fbe585dd458579b/i386/i386/mp_desc.c#L180) + + These articles shows some annotations about how to do the AP Startup: + + - [Reference1](https://wiki.osdev.org/Symmetric_Multiprocessing#AP_startup), + - [Reference2](https://stackoverflow.com/a/16368043/7077301) (...) + + After implement IPI support, It's recommended reimplement `machine_idle()`, + `machine_relax ()`, `halt_cpu()` and `halt_all_cpus()` using IPI. + - [reference](https://github.com/AlmuHS/GNUMach_SMP/blob/0d490ef21c156907f3f26a6cdc00842f462a877a/i386/i386at/model_dep.c#L201) + - Also in `ast_check.c`, we have to implement both functions, using + IPI + [Reference](https://github.com/AlmuHS/GNUMach_SMP/blob/master/i386/i386/ast_check.c) + + + This functions must force the processors to check if there are any AST + signal, and we ought to keep in the mind the following irc chat: + + +> <AlmuHS> what is the use of AST in gnumach? <br/> +> <AlmuHS> this file what do? <br/> +> https://github.com/AlmuHS/GNUMach_SMP/blob/master/i386/i386/ast_check.c <br/> +> <youpi> I don't know <br/> +> <youpi> but look at what calls that <br/> +> <youpi> see e.g. the call in thread.c <br/> +> <AlmuHS> This <br/> +> function is called during the sequence of cpu_up(), in machine.c <br/> +> <AlmuHS> but only if NCPUS > 1 <br/> +> <youpi> it seems like it's to trigger an AST check on another <br/> +> processor <br/> +> <youpi> i.e. a processor tells another to run ast_check <br/> +> <youpi> (see the comment in thread.c) <br/> +> <AlmuHS> <br/> +> https://github.com/AlmuHS/GNUMach_SMP/blob/master/kern/machine.c <br/> +> <youpi> well, the initialization part is not necessarily what's +> important to <br/> +> think about at first <br/> +> <youpi> i.e. until you know what you'll have <br/> +> to do during execution, you don't know what you'll need to intialize at <br/> +> initialization <br/> +> <youpi> you might even not need to initialize anything <br/> +> <AlmuHS> then, this is the reason because all functions <br/> +> in ast_check.c are empty <br/> +> <youpi> cause_ast_check being empty is really probably a TODO <br/> +> <AlmuHS> but I'm not clear what I need to write in this functions <br/> +> <youpi> what the comment said: make another processor run ast_check() <br/> +> <youpi> which probably means raising an inter-processor interrupt <br/> +> <youpi> (aka IPI) <br/> +> <youpi> to get ast_check() called by the other processor <br/> +> <AlmuHS> then, this funcions must raise an IPI in the processor? <br/> +> <youpi> that's the idea <br/> +> <youpi> the IPI probably needs some setup <br/> + +We can use [XV6 source + code](https://pdos.csail.mit.edu/6.828/2018/xv6.html). as model to implements + the function and routines. Some interesting files are + [`lapic.c`](https://github.com/mit-pdos/xv6-public/blob/master/lapic.c), + [`proc.c`](https://github.com/mit-pdos/xv6-public/blob/master/proc.c) and + [`main.c`](https://github.com/mit-pdos/xv6-public/blob/master/main.c) + + +## References +- [Comments about the project bug-hurd +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](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) +- [Mach boot trace](https://www.gnu.org/software/hurd/microkernel/mach/gnumach/boot_trace.html) +- [SPL man page](https://man.openbsd.org/spl) +- [Book: The Mach System](http://codex.cs.yale.edu/avi/os-book/OS9/appendices-dir/b.pdf) +- [Book: Mach3 Mysteries](http://www.nv50.0fees.net/Doc/Mach3Mysteries.pdf) +- [X15 operating system](https://www.sceen.net/x15) +- [Symmetric Multiprocessing - OSDev Wiki](https://wiki.osdev.org/Symmetric_Multiprocessing) +- [**Intel® 64 and IA-32 Architectures Software Developer’s Manuals**](https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf) +- [**Intel Developer Guide, Volume 3: System Programming Guide**](https://software.intel.com/sites/default/files/managed/a4/60/325384-sdm-vol-3abcd.pdf) + + +See also the [[FAQ entry|faq/smp]]. - <braunr> also, while the problem with hurd is about I/O, it's actually a - lot more about caching, and even with more data cached in, the true - problem is contention, in which case having several processors would - actually slow things down even more 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. |
