summaryrefslogtreecommitdiff
path: root/open_issues
diff options
context:
space:
mode:
authorSamuel Thibault <samuel.thibault@ens-lyon.org>2015-02-18 00:58:35 +0100
committerSamuel Thibault <samuel.thibault@ens-lyon.org>2015-02-18 00:58:35 +0100
commit49a086299e047b18280457b654790ef4a2e5abfa (patch)
treec2b29e0734d560ce4f58c6945390650b5cac8a1b /open_issues
parente2b3602ea241cd0f6bc3db88bf055bee459028b6 (diff)
Revert "rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn"
This reverts commit 95878586ec7611791f4001a4ee17abf943fae3c1.
Diffstat (limited to 'open_issues')
-rw-r--r--open_issues/64-bit_port.mdwn72
-rw-r--r--open_issues/Upstart.mdwn61
-rw-r--r--open_issues/_san.mdwn64
-rw-r--r--open_issues/active_vs_passive_symlink_translator.mdwn44
-rw-r--r--open_issues/address_space_memory_mapping_entries.mdwn22
-rw-r--r--open_issues/adduser.mdwn37
-rw-r--r--open_issues/alarm_setitimer.mdwn182
-rw-r--r--open_issues/anatomy_of_a_hurd_system.mdwn1430
-rw-r--r--open_issues/arm_port.mdwn267
-rw-r--r--open_issues/automatic_backtraces_when_assertions_hit.mdwn79
-rw-r--r--open_issues/automatically_checking_port_deallocation.mdwn32
-rw-r--r--open_issues/bash.mdwn59
-rw-r--r--open_issues/bash_busy-loop.mdwn33
-rw-r--r--open_issues/bash_interrupted_system_call.mdwn19
-rw-r--r--open_issues/bash_vs_screen_vs_sigint.mdwn12
-rw-r--r--open_issues/benefits_of_a_native_hurd_implementation.mdwn139
-rw-r--r--open_issues/binutils.mdwn954
-rw-r--r--open_issues/blkrrpart_ioctl.mdwn32
-rw-r--r--open_issues/boehm_gc.mdwn553
-rw-r--r--open_issues/bpf.mdwn654
-rw-r--r--open_issues/bsd_compatibility.mdwn34
-rw-r--r--open_issues/cannot_create__dev_null__interrupted_system_call.mdwn193
-rw-r--r--open_issues/chroot_difference_from_linux.mdwn17
-rw-r--r--open_issues/clock_gettime.mdwn348
-rw-r--r--open_issues/code_analysis.mdwn277
-rw-r--r--open_issues/code_analysis/discussion.mdwn245
-rw-r--r--open_issues/console_tty1.mdwn151
-rw-r--r--open_issues/console_vs_xorg.mdwn31
-rw-r--r--open_issues/contributing.mdwn44
-rw-r--r--open_issues/crash_server.mdwn270
-rw-r--r--open_issues/crashes_vs_system_load_cpu_load_rpc_load.mdwn17
-rw-r--r--open_issues/crt0_o_crt1_o_debug_info_relocation_invalid_symbol_index.mdwn41
-rw-r--r--open_issues/cvs_tasks_file.mdwn18
-rw-r--r--open_issues/cvs_todo_file.mdwn18
-rw-r--r--open_issues/dbus.mdwn502
-rw-r--r--open_issues/dbus_in_linux_kernel.mdwn164
-rw-r--r--open_issues/dde.mdwn661
-rw-r--r--open_issues/debian_cross_toolchain.mdwn15
-rw-r--r--open_issues/debootstrap.mdwn24
-rw-r--r--open_issues/debugging.mdwn56
-rw-r--r--open_issues/debugging_gnumach_startup_qemu_gdb.mdwn165
-rw-r--r--open_issues/default_pager.mdwn44
-rw-r--r--open_issues/dev_zero_size.mdwn21
-rw-r--r--open_issues/device_drivers_and_io_systems.mdwn100
-rw-r--r--open_issues/dir-lookup_authority.mdwn68
-rw-r--r--open_issues/duplicate_inclusion_guards.mdwn16
-rw-r--r--open_issues/e2fsck_i_file_acl_hi.mdwn40
-rw-r--r--open_issues/elinks.mdwn28
-rw-r--r--open_issues/emacs.mdwn1542
-rw-r--r--open_issues/error_message_disk_full.mdwn14
-rw-r--r--open_issues/etc_fstab.mdwn18
-rw-r--r--open_issues/exec.mdwn84
-rw-r--r--open_issues/exec_memory_leaks.mdwn121
-rw-r--r--open_issues/ext2fs_deadlock.mdwn54
-rw-r--r--open_issues/ext2fs_dtime.mdwn21
-rw-r--r--open_issues/ext2fs_libports_reference_counting_assertion.mdwn111
-rw-r--r--open_issues/ext2fs_page_cache_swapping_leak.mdwn361
-rw-r--r--open_issues/extern_inline.mdwn109
-rw-r--r--open_issues/faccessat.mdwn21
-rw-r--r--open_issues/fakeroot_eagain.mdwn216
-rw-r--r--open_issues/fakeroot_exit_0.mdwn35
-rw-r--r--open_issues/fcntl_F_SETFL_FD.mdwn26
-rw-r--r--open_issues/fcntl_locking_dev_null.mdwn38
-rw-r--r--open_issues/fdisk.mdwn19
-rw-r--r--open_issues/fifo_O_RDWR.mdwn25
-rw-r--r--open_issues/fifo_thread_explosion.mdwn20
-rw-r--r--open_issues/file_locking.mdwn98
-rw-r--r--open_issues/file_system_exerciser.mdwn31
-rw-r--r--open_issues/fork_deadlock.mdwn3566
-rw-r--r--open_issues/fork_mach_port_mod_refs_ekern_urefs_owerflow.mdwn185
-rw-r--r--open_issues/formal_verification.mdwn33
-rw-r--r--open_issues/fsync.mdwn22
-rw-r--r--open_issues/gcc.mdwn1354
-rw-r--r--open_issues/gcc/libmudflap.mdwn74
-rw-r--r--open_issues/gcc/pie.mdwn51
-rw-r--r--open_issues/gccgo.mdwn149
-rw-r--r--open_issues/gdb-heap.mdwn15
-rw-r--r--open_issues/gdb.mdwn12
-rw-r--r--open_issues/gdb/gdbserver.mdwn20
-rw-r--r--open_issues/gdb_attach.mdwn83
-rw-r--r--open_issues/gdb_catch_syscall.mdwn18
-rw-r--r--open_issues/gdb_gcore.mdwn30
-rw-r--r--open_issues/gdb_non-stop_mode.mdwn26
-rw-r--r--open_issues/gdb_noninvasive_mode_new_threads.mdwn15
-rw-r--r--open_issues/gdb_pending_execs.mdwn30
-rw-r--r--open_issues/gdb_signal_handler.mdwn474
-rw-r--r--open_issues/gdb_signal_thread_bt.mdwn31
-rw-r--r--open_issues/gdb_thread_ids.mdwn31
-rw-r--r--open_issues/git-core-2.mdwn323
-rw-r--r--open_issues/git_duplicated_content.mdwn128
-rw-r--r--open_issues/git_nfs_mmap.mdwn55
-rw-r--r--open_issues/glibc.mdwn3422
-rw-r--r--open_issues/glibc/debian.mdwn168
-rw-r--r--open_issues/glibc/debian/experimental.mdwn338
-rw-r--r--open_issues/glibc/mremap.mdwn70
-rw-r--r--open_issues/glibc/octave.mdwn35
-rw-r--r--open_issues/glibc/t/tls-threadvar.mdwn155
-rw-r--r--open_issues/glibc/t/tls.mdwn81
-rw-r--r--open_issues/glibc___libc_alloca_cutoff_should_be_lowered.mdwn19
-rw-r--r--open_issues/glibc_ioctls.mdwn171
-rw-r--r--open_issues/glibc_libpthread_robust_mutexes.mdwn54
-rw-r--r--open_issues/glibc_madvise_vs_static_linking.mdwn48
-rw-r--r--open_issues/glibc_ptrace.mdwn43
-rw-r--r--open_issues/glibc_tls_segment_tcbhead_t_dtv_offset.mdwn28
-rw-r--r--open_issues/glusterfs.mdwn15
-rw-r--r--open_issues/gnat.mdwn167
-rw-r--r--open_issues/gnumach_PCI_access.mdwn18
-rw-r--r--open_issues/gnumach_console_timestamp.mdwn29
-rw-r--r--open_issues/gnumach_constants.mdwn32
-rw-r--r--open_issues/gnumach_general_protection_trap_gdb_vm_read.mdwn142
-rw-r--r--open_issues/gnumach_i686.mdwn26
-rw-r--r--open_issues/gnumach_integer_overflow.mdwn50
-rw-r--r--open_issues/gnumach_kernel_threads.mdwn23
-rw-r--r--open_issues/gnumach_memory_management.mdwn2391
-rw-r--r--open_issues/gnumach_memory_management_2.mdwn246
-rw-r--r--open_issues/gnumach_memory_management_physical_memory.mdwn46
-rw-r--r--open_issues/gnumach_page_cache_policy.mdwn873
-rw-r--r--open_issues/gnumach_panic_thread_dispatch.mdwn20
-rw-r--r--open_issues/gnumach_rpc_timeouts.mdwn19
-rw-r--r--open_issues/gnumach_tick.mdwn38
-rw-r--r--open_issues/gnumach_tlb_flushing.mdwn21
-rw-r--r--open_issues/gnumach_vm_map_entry_forward_merging.mdwn202
-rw-r--r--open_issues/gnumach_vm_map_red-black_trees.mdwn346
-rw-r--r--open_issues/gnumach_vm_object_resident_page_count.mdwn54
-rw-r--r--open_issues/hurd_101.mdwn360
-rw-r--r--open_issues/hurd_build_without_parted.mdwn16
-rw-r--r--open_issues/hurd_file_name_lookup_retry_FS_RETRY_MAGIC.mdwn50
-rw-r--r--open_issues/hurd_init.mdwn224
-rw-r--r--open_issues/hurdextras.mdwn95
-rw-r--r--open_issues/ifunc.mdwn49
-rw-r--r--open_issues/implementing_hurd_on_top_of_another_system.mdwn420
-rw-r--r--open_issues/inotify_file_notice_changes.mdwn47
-rw-r--r--open_issues/issue_tracking.mdwn196
-rw-r--r--open_issues/keymap_mach_console.mdwn40
-rw-r--r--open_issues/kvm.mdwn37
-rw-r--r--open_issues/largefile.mdwn21
-rw-r--r--open_issues/latrace.mdwn16
-rw-r--r--open_issues/lexical_dot-dot.mdwn20
-rw-r--r--open_issues/libc_variant_selection.mdwn57
-rw-r--r--open_issues/libdiskfs_dot_dot-dot_relevant_for_libnetfs.mdwn20
-rw-r--r--open_issues/libfshelp_in_hurdlibs.mdwn17
-rw-r--r--open_issues/libgomp_pthread_attr_setstacksize_pthread_stack_min.mdwn17
-rw-r--r--open_issues/libmachuser_libhurduser_rpc_stubs.mdwn177
-rw-r--r--open_issues/libnetfs_io_map.mdwn42
-rw-r--r--open_issues/libnetfs_passive_translators.mdwn55
-rw-r--r--open_issues/libnetfs_vs_libdiskfs.mdwn118
-rw-r--r--open_issues/libnfs.mdwn28
-rw-r--r--open_issues/libpager_deadlock.mdwn165
-rw-r--r--open_issues/libpthread.mdwn2414
-rw-r--r--open_issues/libpthread/t/fix_have_kernel_resources.mdwn1301
-rw-r--r--open_issues/libpthread_1fcd93fd3c733eb19bcad8d03e65f13ec4b0e998..master-viengoos-on-bare-metal.mdwn849
-rw-r--r--open_issues/libpthread_CLOCK_MONOTONIC.mdwn120
-rw-r--r--open_issues/libpthread_addon.mdwn135
-rw-r--r--open_issues/libpthread_assertion_thread_prevp.mdwn109
-rw-r--r--open_issues/libpthread_cancellation_points.mdwn139
-rw-r--r--open_issues/libpthread_dlopen.mdwn244
-rw-r--r--open_issues/libpthread_glibc_nptl_testsuite.mdwn26
-rw-r--r--open_issues/libpthread_set_stack_size.mdwn114
-rw-r--r--open_issues/libpthread_timeout_dequeue.mdwn22
-rw-r--r--open_issues/libpthread_weak_symbols.mdwn50
-rw-r--r--open_issues/librpci.mdwn31
-rw-r--r--open_issues/libstore_parted.mdwn11
-rw-r--r--open_issues/libtool.mdwn19
-rw-r--r--open_issues/linux_as_the_kernel.mdwn268
-rw-r--r--open_issues/linux_vmsig.mdwn44
-rw-r--r--open_issues/lisp_cross-compile.mdwn11
-rw-r--r--open_issues/llvm.mdwn398
-rw-r--r--open_issues/locking_issues.mdwn48
-rw-r--r--open_issues/low_memory.mdwn113
-rw-r--r--open_issues/lsof.mdwn51
-rw-r--r--open_issues/ltrace.mdwn27
-rw-r--r--open_issues/m4_vs_stack.mdwn21
-rw-r--r--open_issues/mach-defpager_debugging.mdwn22
-rw-r--r--open_issues/mach-defpager_malloc_hook.mdwn14
-rw-r--r--open_issues/mach-defpager_swap.mdwn41
-rw-r--r--open_issues/mach-defpager_vs_defpager.mdwn33
-rw-r--r--open_issues/mach_federations.mdwn66
-rw-r--r--open_issues/mach_migrating_threads.mdwn118
-rw-r--r--open_issues/mach_on_top_of_posix.mdwn18
-rw-r--r--open_issues/mach_shadow_objects.mdwn24
-rw-r--r--open_issues/mach_tasks_memory_usage.mdwn175
-rw-r--r--open_issues/mach_vm_pageout.mdwn19
-rw-r--r--open_issues/magic_translator_machtype.mdwn28
-rw-r--r--open_issues/managed_runtime_initiative.mdwn72
-rw-r--r--open_issues/memory_object_model_vs_block-level_cache.mdwn514
-rw-r--r--open_issues/metadata_caching.mdwn31
-rw-r--r--open_issues/mig_error_reply.mdwn68
-rw-r--r--open_issues/mig_portable_rpc_declarations.mdwn291
-rw-r--r--open_issues/mig_strings.mdwn38
-rw-r--r--open_issues/mig_stub_functions.mdwn53
-rw-r--r--open_issues/mission_statement.mdwn708
-rw-r--r--open_issues/mmap_crash_etc.mdwn95
-rw-r--r--open_issues/mmap_write-only.mdwn57
-rw-r--r--open_issues/mondriaan_memory_protection.mdwn85
-rw-r--r--open_issues/multiprocessing.mdwn77
-rw-r--r--open_issues/multithreading.mdwn601
-rw-r--r--open_issues/multithreading/erlang-style_parallelism.mdwn204
-rw-r--r--open_issues/neals_hurd-misc_papers.mdwn16
-rw-r--r--open_issues/netstat.mdwn34
-rw-r--r--open_issues/network_file_system_by_just_forwarding_rpcs.mdwn21
-rw-r--r--open_issues/nfs_trailing_slash.mdwn36
-rw-r--r--open_issues/nice_changes_priority_of_parent_shell.mdwn15
-rw-r--r--open_issues/nice_vs_mach_thread_priorities.mdwn429
-rw-r--r--open_issues/nightly_builds.mdwn53
-rw-r--r--open_issues/nightly_builds_deb_packages.mdwn747
-rw-r--r--open_issues/notmuch_n_gmane.mdwn18
-rw-r--r--open_issues/nptl.mdwn116
-rw-r--r--open_issues/o_exec.mdwn54
-rw-r--r--open_issues/ogi.mdwn54
-rw-r--r--open_issues/open_posix_test_suite.mdwn2725
-rw-r--r--open_issues/open_symlink.mdwn30
-rw-r--r--open_issues/osf_mach.mdwn237
-rw-r--r--open_issues/packaging_libpthread.mdwn236
-rw-r--r--open_issues/page_cache.mdwn79
-rw-r--r--open_issues/pci_arbiter.mdwn256
-rw-r--r--open_issues/performance.mdwn260
-rw-r--r--open_issues/performance/degradation.mdwn52
-rw-r--r--open_issues/performance/fork.mdwn37
-rw-r--r--open_issues/performance/io_system/binutils_ld_64ksec.mdwn39
-rw-r--r--open_issues/performance/io_system/clustered_page_faults.mdwn165
-rw-r--r--open_issues/performance/io_system/read-ahead.mdwn3076
-rw-r--r--open_issues/performance/ipc_virtual_copy.mdwn395
-rw-r--r--open_issues/performance/microbenchmarks.mdwn13
-rw-r--r--open_issues/performance/microkernel_multi-server.mdwn226
-rw-r--r--open_issues/perl.mdwn113
-rw-r--r--open_issues/perlmagick.mdwn107
-rw-r--r--open_issues/pfinet.mdwn27
-rw-r--r--open_issues/pfinet_timers.mdwn177
-rw-r--r--open_issues/pfinet_vs_system_time_changes.mdwn101
-rw-r--r--open_issues/pflocal_reauth.mdwn42
-rw-r--r--open_issues/pflocal_socket_credentials_for_local_sockets.mdwn66
-rw-r--r--open_issues/pflocal_x_slowness.mdwn16
-rw-r--r--open_issues/phython.mdwn13
-rw-r--r--open_issues/placement_of_virtual_memory_regions.mdwn103
-rw-r--r--open_issues/populate_hurd_git_with_submodules_etc.mdwn16
-rw-r--r--open_issues/posix_fadv_volatile.mdwn16
-rw-r--r--open_issues/prelink.mdwn27
-rw-r--r--open_issues/problematic_packages.mdwn31
-rw-r--r--open_issues/proc_server_proc_exception_raise.mdwn37
-rw-r--r--open_issues/procfs_umount.mdwn24
-rw-r--r--open_issues/profiling.mdwn371
-rw-r--r--open_issues/ps_SIGSEGV.mdwn17
-rw-r--r--open_issues/pth.mdwn28
-rw-r--r--open_issues/pthread_atfork.mdwn111
-rw-r--r--open_issues/python.mdwn47
-rw-r--r--open_issues/resource_management_problems.mdwn131
-rw-r--r--open_issues/resource_management_problems/configure_max_command_line_length.mdwn17
-rw-r--r--open_issues/resource_management_problems/io_accounting.mdwn49
-rw-r--r--open_issues/resource_management_problems/pagers.mdwn322
-rw-r--r--open_issues/resource_management_problems/zalloc_panics.mdwn99
-rw-r--r--open_issues/rework_gnumach_ipc_spaces.mdwn728
-rw-r--r--open_issues/rm_fr.mdwn39
-rw-r--r--open_issues/robustness.mdwn217
-rw-r--r--open_issues/rpc_stub_generator.mdwn146
-rw-r--r--open_issues/rpc_to_self_with_rendez-vous_leading_to_duplicate_port_destroy.mdwn163
-rw-r--r--open_issues/runit.mdwn50
-rw-r--r--open_issues/sa_siginfo_sa_sigaction.mdwn96
-rw-r--r--open_issues/sbcl.mdwn31
-rw-r--r--open_issues/screen.mdwn120
-rw-r--r--open_issues/screen_dead_session.mdwn69
-rw-r--r--open_issues/secure_file_descriptor_handling.mdwn28
-rw-r--r--open_issues/security.mdwn28
-rw-r--r--open_issues/select.mdwn2440
-rw-r--r--open_issues/select_bogus_fd.mdwn55
-rw-r--r--open_issues/select_vs_signals.mdwn62
-rw-r--r--open_issues/sendmsg_scm_creds.mdwn172
-rw-r--r--open_issues/serial_console.mdwn106
-rw-r--r--open_issues/servers_default-pager_permissions.mdwn27
-rw-r--r--open_issues/settrans_directory_symlink.mdwn52
-rw-r--r--open_issues/sigpipe.mdwn345
-rw-r--r--open_issues/smp.mdwn47
-rw-r--r--open_issues/socat.mdwn15
-rw-r--r--open_issues/some_todo_list.mdwn112
-rw-r--r--open_issues/ssh.mdwn20
-rw-r--r--open_issues/strict_aliasing.mdwn44
-rw-r--r--open_issues/subhurd_error_messages.mdwn15
-rw-r--r--open_issues/subhurd_vs_proc_server.mdwn54
-rw-r--r--open_issues/sync_but_still_unclean_filesystem.mdwn39
-rw-r--r--open_issues/synchronous_ipc.mdwn185
-rw-r--r--open_issues/syslog.mdwn116
-rw-r--r--open_issues/system_call_mechanism.mdwn56
-rw-r--r--open_issues/system_crash_nmap.mdwn15
-rw-r--r--open_issues/system_crash_pflocal_fifo.mdwn41
-rw-r--r--open_issues/system_initialization.mdwn42
-rw-r--r--open_issues/system_stats.mdwn45
-rw-r--r--open_issues/systemd.mdwn3694
-rw-r--r--open_issues/term_blocking.mdwn339
-rw-r--r--open_issues/term_blocking/2011-07-04.mdwn246
-rw-r--r--open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.mdwn54
-rw-r--r--open_issues/thread_numbering_of_ps_and_gdb.mdwn21
-rw-r--r--open_issues/threads_issues.mdwn15
-rw-r--r--open_issues/ti-rpc_then_nfs.mdwn132
-rw-r--r--open_issues/time.mdwn853
-rw-r--r--open_issues/tinyproxy.mdwn18
-rw-r--r--open_issues/tmux.mdwn57
-rw-r--r--open_issues/translate_fd_or_port_to_file_name.mdwn280
-rw-r--r--open_issues/translator_environment_variables.mdwn31
-rw-r--r--open_issues/translator_stdout_stderr.mdwn114
-rw-r--r--open_issues/translators_O_NOTRANS_O_NOFOLLOW_namespace-based_selection.mdwn148
-rw-r--r--open_issues/translators_set_up_by_untrusted_users.mdwn583
-rw-r--r--open_issues/trust_the_behavior_of_translators.mdwn181
-rw-r--r--open_issues/tty_activitiy_vs_disk_io.mdwn81
-rw-r--r--open_issues/unit_testing.mdwn94
-rw-r--r--open_issues/user-space_device_drivers.mdwn1148
-rw-r--r--open_issues/usleep.mdwn25
-rw-r--r--open_issues/vdso.mdwn48
-rw-r--r--open_issues/versioning.mdwn109
-rw-r--r--open_issues/vfat_test_suite.mdwn20
-rw-r--r--open_issues/viengoos_make_clean.mdwn22
-rw-r--r--open_issues/viengoos_tls_gcc.mdwn17
-rw-r--r--open_issues/virtio.mdwn208
-rw-r--r--open_issues/virtual_square_view-os.mdwn55
-rw-r--r--open_issues/virtualbox.mdwn137
-rw-r--r--open_issues/virtualization.mdwn50
-rw-r--r--open_issues/virtualization/capsicum.mdwn22
-rw-r--r--open_issues/virtualization/fakeroot.mdwn1330
-rw-r--r--open_issues/virtualization/file_systems.mdwn24
-rw-r--r--open_issues/virtualization/networking.mdwn88
-rw-r--r--open_issues/virtualization/remap_root_translator.mdwn157
-rw-r--r--open_issues/visudo.mdwn22
-rw-r--r--open_issues/vm_map_kernel_bug.mdwn71
-rw-r--r--open_issues/wait_errors.mdwn25
-rw-r--r--open_issues/wayland.mdwn33
-rw-r--r--open_issues/whole_system_debugging.mdwn19
-rw-r--r--open_issues/wine.mdwn182
-rw-r--r--open_issues/wrong_reply_message_id.mdwn23
-rw-r--r--open_issues/xattr.mdwn55
-rw-r--r--open_issues/xen_crash_copy-size_le_page_size.mdwn104
-rw-r--r--open_issues/xen_domu_with_ro_hd.mdwn35
-rw-r--r--open_issues/xen_lseek.mdwn57
-rw-r--r--open_issues/xorg_porting.mdwn16
331 files changed, 68126 insertions, 0 deletions
diff --git a/open_issues/64-bit_port.mdwn b/open_issues/64-bit_port.mdwn
new file mode 100644
index 00000000..04273630
--- /dev/null
+++ b/open_issues/64-bit_port.mdwn
@@ -0,0 +1,72 @@
+[[!meta copyright="Copyright © 2011, 2012, 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]]."]]"""]]
+
+[[!tag open_issue_gnumach open_issue_mig]]
+
+There is a `master-x86_64` GNU Mach branch. As of 2012-11-20, it only supports
+the [[microkernel/mach/gnumach/ports/Xen]] platform.
+
+
+# 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]].
diff --git a/open_issues/Upstart.mdwn b/open_issues/Upstart.mdwn
new file mode 100644
index 00000000..c8a8347d
--- /dev/null
+++ b/open_issues/Upstart.mdwn
@@ -0,0 +1,61 @@
+[[!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]]."]]"""]]
+
+Upstart is an event based init system that is GPL licensed, however upstream
+contributions are under a CLA that permits proprietary relicensing.
+
+As of Jan 2 2013, Debian is considering adopting Upstart as an init system on
+GNU/Linux, and on GNU/kFreeBSD when the port to kFreeBSD is finished.
+
+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/_san.mdwn b/open_issues/_san.mdwn
new file mode 100644
index 00000000..5e6c8796
--- /dev/null
+++ b/open_issues/_san.mdwn
@@ -0,0 +1,64 @@
+[[!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]]."]]"""]]
+
+[[!meta title="Port the GCC and LLVM/clang Sanitizers (*san) to the Hurd"]]
+
+[[!tag open_issue_gcc]]
+
+GCC and LLVM/clang provide several *sanitizers*,
+<http://clang.llvm.org/docs/UsersManual.html#controlling-code-generation>, such
+as:
+
+ * Address Sanitizer, a memory error detector (ASan; `-fsanitize=address`)
+
+ [Finding races and memory errors with GCC instrumentation
+ (AddressSanitizer)](http://gcc.gnu.org/wiki/cauldron2012#Finding_races_and_memory_errors_with_GCC_instrumentation_.28AddressSanitizer.29),
+ GNU Tools Cauldron 2012. <http://code.google.com/p/address-sanitizer/>.
+
+ * Memory Sanitizer, an detector of uninitialized reads (MSan;
+ `-fsanitize=memory`)
+
+ <http://code.google.com/p/memory-sanitizer/>
+
+ * Thread Sanitizer, a data race detector (TSan; `-fsanitize=thread`)
+
+ <http://code.google.com/p/data-race-test/wiki/ThreadSanitizer>
+
+ * Undefined Behavior Sanitizer (UBsan; `-fsanitize=undefined`)
+
+Porting these to the Hurd is not a trivial task, for they have intimate
+knowledge about the operating system kernel they're running on, and from a
+first look they reimplement a lot of [[/glibc]] by directly using
+[[system_call]]s -- which is basically a no-go on GNU Hurd.
+
+
+# IRC, OFTC, #gcc, 2012-12-11
+
+ <richi> hmm, is libtsan not multi-libbed?
+ <jakub> richi: it only works on x86_64 right now
+ <richi> ugh
+ <jakub> richi: so, it is multilibbed, but only built on multilibs and
+ targets which are supported
+ <jakub> richi: as it often needs lots of RAM, it is probably not going to
+ be supported on 32-bit targets at all
+ <jakub> richi: no reason not to support it on say ppc64 or sparc64 or s390x
+ I guess, just needs work
+ <richi> jakub: where is asan supported? everywhere?
+ <jakub> richi: but then, I haven't even read what exactly libtsan does,
+ only looked at the atomics in there, and did the GCC side from what I
+ knew should be instrumented
+ <jakub> richi: asan is right now supported on x86_64/i686, ppc/ppc64,
+ perhaps partially x86 darwin (don't care) and in theory arm (nobody
+ tested)
+ <jakub> richi: porting isn't that hard, but the library isn't as clean as
+ it would be desirable portability wise
+ <jakub> richi: that said, I don't want to spend as much time as I've done
+ so far on it, and in the time I'll allocate for it optimizing the code it
+ generates is higher on the todo list than ports to other targets
diff --git a/open_issues/active_vs_passive_symlink_translator.mdwn b/open_issues/active_vs_passive_symlink_translator.mdwn
new file mode 100644
index 00000000..cbd9b077
--- /dev/null
+++ b/open_issues/active_vs_passive_symlink_translator.mdwn
@@ -0,0 +1,44 @@
+[[!meta copyright="Copyright © 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_documentation open_issue_hurd]]
+
+IRC, freenode, #hurd, 2011-07-25
+
+Set an *active* (not *passive*) `/hurd/symlink` translator on a node.
+
+ < antrik> that's strange: the file doesn't look like a symlink in ls output
+ -- but it behaves like one...
+ < antrik> using firmlink instead of symlink yields less confusing
+ results...
+ < gg0> how does it behaves like one?
+ < antrik> perhaps the symlink mechanism only fully works for a passive
+ symlink translator, not an active one
+ < antrik> gg0: if you access it, you actually get the linked file contents
+ < antrik> it's only ls that's confused
+ < antrik> it might be because ls -l uses O_NOFOLLOW, which results in
+ O_NOTRANS, so it sees the original file contents
+ < gg0> stat says it's still 12264 bytes
+ < antrik> stat also seems to use NOFOLLOW
+ < antrik> wc will show the "correct" size
+ < gg0> ok
+ < antrik> if you set it as passive translator, it works as expected... but
+ then you better don't forget removing it, as it won't go away after a
+ reboot :-)
+ < antrik> but as I said, you can just ignore the weirdness -- or use
+ firmlink instead
+ < antrik> the thing is, if symlink is set as a passive translator, the
+ filesystem handles it specially, so it really looks like a symlink to
+ programs using NOFOLLOW. that's not the case with an active symlink... so
+ programs using NOFOLLOW simply do not see the active symlink at all
+ < antrik> firmlink OTOH ignores NOFOLLOW, so you always see the linked-to
+ file
+
+ * [[hurd/translator/short-circuiting]]
diff --git a/open_issues/address_space_memory_mapping_entries.mdwn b/open_issues/address_space_memory_mapping_entries.mdwn
new file mode 100644
index 00000000..f1811b27
--- /dev/null
+++ b/open_issues/address_space_memory_mapping_entries.mdwn
@@ -0,0 +1,22 @@
+[[!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_gnumach]]
+
+IRC, freenode, #hurd, 2011-05-07
+
+ <braunr> and as a last example: memory mapping is heavily used in the hurd,
+ but for some reason, the map entries in an address space are still on a
+ linked list
+ <braunr> a bare linked list
+ <braunr> which makes faults and page cache lookups even slower
+
+A [[red-black tree|gnumach_vm_map_red-black_trees]] was added to VM maps to
+speed up lookups.
diff --git a/open_issues/adduser.mdwn b/open_issues/adduser.mdwn
new file mode 100644
index 00000000..713a1dd3
--- /dev/null
+++ b/open_issues/adduser.mdwn
@@ -0,0 +1,37 @@
+[[!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
new file mode 100644
index 00000000..a1c8a7d3
--- /dev/null
+++ b/open_issues/alarm_setitimer.mdwn
@@ -0,0 +1,182 @@
+[[!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]]."]]"""]]
+
+[[!meta title="alarm/setitimer"]]
+
+[[!tag open_issue_glibc open_issue_hurd]]
+
+`setitimer()`, called by `alarm()` when setting a new alarm, it is not able
+to disable on its own the timer when the alarm is fired the first time.
+On the other hand, manually invoking `alarm(0)` can cancel the running timer
+for `SIGALRM`.
+
+See also the attached file: on other OSes (e.g. Linux) it blocks waiting
+for a signal, while on GNU/Hurd it gets a new alarm and exits.
+
+[[alrm.c]]
+
+This issue was recently fixed (around January 2013).
+
+# IRC, freenode, #hurd, 2012-07-29
+
+ <braunr> our setitimer is bugged
+ <braunr> it seems doesn't seem to leave a timer disarmed when the interval
+ is set to 0
+ <braunr> (which means a one shot timer is actually periodic ..)
+
+
+## IRC, freenode, #hurd, 2012-12-26
+
+ <braunr> youpi: tschwinge: the setitimer issue
+ http://www.gnu.org/software/hurd/open_issues/alarm_setitimer.html) is
+ because of the global preemptor installed by setitimer not being run when
+ sigalrm is catched
+ <braunr> if anyone has a good definition for a preemptor, let us know (mine
+ is currently "something that is scanned on signal delivery and can alter
+ this delivery")
+ <youpi> I don't have any better definition
+ <pinotree> braunr: ah, that explains indeed
+ <pinotree> thanks
+ <braunr> i think i found the problem :)
+ <braunr> seems to be a minor overlook from drepper
+ <braunr> (or the real author if he was only the committer)
+ <braunr> hurd_preempt_signals augments _hurdsig_preempted_set with the
+ signals from the installed preemptor
+ <braunr> but the inline version in setitimer doesn't
+ <braunr> and post_signal actually checks that
+ <braunr> the preemptor itself looks wrong, since its sigcode range is 0, 0
+ whereas SI_TIMER is used when raising SIGALRM ...
+ <braunr> ah but that's a recent change, right
+ <braunr> it came with "implement SA_SIGINFO signal handlers"
+ (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
+ <youpi> and pushed to the debian package
+
+
+## IRC, freenode, #hurd, 2012-12-27
+
+ <braunr> do we know any application that was broken because of setitimer ?
+ <pinotree> braunr: bits in the python and perl test suites
+ <braunr> ok
+
+
+## IRC, freenode, #hurd, 2012-12-28
+
+ <pinotree> braunr: ah, also libglib-perl's testsuite is affected by the
+ alarm/setitimer issue
+ <braunr> pinotree: only tests ? :(
+ <pinotree> braunr: yeah
+ <braunr> ok, we don't win that much on this fix, but anyway, still good to
+ have
+ <pinotree> but that source is pretty quick to compile and check
+ <pinotree> braunr: eh, so far that's what i found myself
+
+
+## IRC, freenode, #hurd, 2013-01-04
+
+See also [[select]].
+
+ <youpi> bummer, we have broken ghc completely with the latest glibc patches
+ <pinotree> youpi: what do you mean?
+ <youpi> pinotree: it just hangs on installation
+
+
+## IRC, freenode, #hurd, 2013-01-05
+
+ <youpi> pinotree: it seems ghc was disturbed by the setitimer patch
+ <youpi> pinotree: http://paste.debian.net/221807/
+ <youpi> pinotree: it seems to be simply due to nested locking of
+ _hurd_siglock :/
+ <youpi> pinotree: I wonder whether this code has ever been really tested
+ <youpi> oops
+ <youpi> braunr: my comments above were for you actually :)
+ <youpi> braunr: see the update I've just commited to the debian patch
+ <youpi> I've added a parameter to setitimer_locked, to know whether the
+ lock is already taken or not
+ <youpi> that does fix ghc
+ <youpi> as well as the gdb ntpdate hang, apparently
+ <youpi> I can confirm that the single-select patch breaks ntpdate for some
+ reason
+ <youpi> I wonder whether it could be due to port set behavior being
+ different from single reply port
+ <youpi> I believe I understand what happens
+
+[[select_vs_signals]].
+
+ <youpi> I'll rebuild ntpdate with a 1s timeout
+ <youpi> that'll at least fix that
+ <youpi> rah, no, doesn't work, it insists on getting its alarm
+ <youpi> Mmm, no, the __mach_msg call doesn't even return
+ <youpi> even though MACH_RCV_TIMEOUT is set, and to is 1000
+ <braunr> youpi: i see
+ <braunr> gnu_srs: and you, see how youpi analysed and understood the
+ problem, instead of just guessing :p
+ <braunr> youpi: it doesn't return ?
+ <braunr> iirc, the __mach_msg wrapper deals with the interruptible flag
+ <youpi> braunr: yes, __mach_msg deals with the interruptible flag by
+ looping !
+ <youpi> and the info page says it: if it's interrupted too often, it may
+ just never return
+ <youpi> that's what actually happens here
+ <youpi> (ntpdate sets an itimer more often than every 1s)
+ <braunr> youpi: ew :)
+ <youpi> I'll test a bit more, and submit a patch
+ <pinotree> youpi: otoh a _locker function usually means it expects a locked
+ mutex ;)
+ <pinotree> i also i wondered whether there could be a race in the settimer
+ mini-thread, between its mach_msg and its reading of the interval
+ <youpi> pinotree: right, we could as well just lock anyway
+ <youpi> there could be indeed
+ <pinotree> youpi: i don't know much about the internals of signal
+ dispatching, but could it happen the following:
+ <pinotree> in timer thread, mach_msg expires → sig_post_request → before
+ the main thread receives/processes the signal, the timer thread iterates
+ again on its while(1), using the same interval previously used
+ <pinotree> ?
+ <youpi> did you check the comment above __msg_sig_post_request?
+ <pinotree> ah ok
+ <youpi> I'm not sure how that works, but it's supposed to :)
+ <pinotree> just wonder: wouldn't it be simplier if the logic to change the
+ timeout would be in the timer thread, instead of relying on the main
+ thread adjusting it?
+ <youpi> maybe there are some semantic details that wouldn't be right with
+ such approach
+ <pinotree> i see
+ <pinotree> i guess so if the new interval is 0, the thread can be properly
+ suspened (or killed, if the former fails)
+ <youpi> could be something like this, yes
+ <pinotree> youpi: ah, wrt your comments of tonight: at least with the
+ current setitimer patch (in -38), a simple alarm() test app works, and i
+ saw few python tests can be reenabled now
+ <youpi> ok
+ <pinotree> so even if not totally correct, at least it had some positive
+ effects
+ <pinotree> youpi: wrt the double lock issue of _hurd_siglock, what about
+ using the "crit" parameter of setitimer_locked?
+ <youpi> it may have various values
+ <youpi> depending whether we're already in the critical section etc.
+ <pinotree> restart_itimer does not take that lock, so we could check
+ whether crit is null, and in that case not even bothering to check the
+ signal preemptors, since it was called as a result of own setitimer
+ thread?
+ <youpi> I'd rather avoid binding whether the mutex is held to whether the
+ call is coming from the actual premptor
+ <youpi> again, crit may be null if we're already in the critical section
+ when setitimer is called
+ <braunr> setitimer already does unclean things with preemptors
+ <youpi> not a good thing to add more :)
+ <pinotree> fair enough, so a simple bool should do the job
+ <braunr> i mean, the whole thing is "cheezoid" :)
+ <braunr> it probably needs a rewrite some day
+ <braunr> so "in the meantime" (of years, i know)
+ <pinotree> braunr: and temporary, too
+ <braunr> but a bool is fine too, sure :)
diff --git a/open_issues/anatomy_of_a_hurd_system.mdwn b/open_issues/anatomy_of_a_hurd_system.mdwn
new file mode 100644
index 00000000..496d2a06
--- /dev/null
+++ b/open_issues/anatomy_of_a_hurd_system.mdwn
@@ -0,0 +1,1430 @@
+[[!meta copyright="Copyright © 2011, 2012, 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]]."]]"""]]
+
+[[!taglink open_issue_documentation]]
+
+A bunch of this should also be covered in other (introductionary) material,
+like Bushnell's Hurd paper. All this should be unfied and streamlined.
+
+[[!toc]]
+
+
+# IRC, freenode, #hurd, 2011-03-08
+
+ <foocraft> I've a question on what are the "units" in the hurd project, if
+ you were to divide them into units if they aren't, and what are the
+ dependency relations between those units(roughly, nothing too pedantic
+ for now)
+ <antrik> there is GNU Mach (the microkernel); there are the server
+ libraries in the Hurd package; there are the actual servers in the same;
+ and there is the POSIX implementation layer in glibc
+ <antrik> relations are a bit tricky
+ <antrik> Mach is the base layer which implements IPC and memory management
+ <foocraft> hmm I'll probably allocate time for dependency graph generation,
+ in the worst case
+ <antrik> on top of this, the Hurd servers, using the server libraries,
+ implement various aspects of the system functionality
+ <antrik> client programs use libc calls to use the servers
+ <antrik> (servers also use libc to communicate with other servers and/or
+ Mach though)
+ <foocraft> so every server depends solely on mach, and no other server?
+ <foocraft> s/mach/mach and/or libc/
+ <antrik> I think these things should be pretty clear one you are somewhat
+ familiar with the Hurd architecture... nothing really tricky there
+ <antrik> no
+ <antrik> servers often depend on other servers for certain functionality
+
+
+# Bootstrap
+
+## [[hurd_init]]
+
+## IRC, freenode, #hurd, 2011-03-12
+
+ <dEhiN> when mach first starts up, does it have some basic i/o or fs
+ functionality built into it to start up the initial hurd translators?
+ <antrik> I/O is presently completely in Mach
+ <antrik> filesystems are in userspace
+ <antrik> the root filesystem and exec server are loaded by grub
+ <dEhiN> o I see
+ <dEhiN> so in order to start hurd, you would have to start mach and
+ simultaneously start the root filesystem and exec server?
+ <antrik> not exactly
+ <antrik> GRUB loads all three, and then starts Mach. Mach in turn starts
+ the servers according to the multiboot information passed from GRUB
+ <dEhiN> ok, so does GRUB load them into ram?
+ <dEhiN> I'm trying to figure out in my mind how hurd is initially started
+ up from a low-level pov
+ <antrik> yes, as I said, GRUB loads them
+ <dEhiN> ok, thanks antrik...I'm new to the idea of microkernels, but a
+ veteran of monolithic kernels
+ <dEhiN> although I just learned that windows nt is a hybrid kernel which I
+ never knew!
+ <rm> note there's a /hurd/ext2fs.static
+ <rm> I belive that's what is used initially... right?
+ <antrik> yes
+ <antrik> loading the shared libraries in addition to the actual server
+ would be unweildy
+ <antrik> so the root FS server is linked statically instead
+ <dEhiN> what does the root FS server do?
+ <antrik> well, it serves the root FS ;-)
+ <antrik> it also does some bootstrapping work during startup, to bring the
+ rest of the system up
+
+
+## IRC, freenode, #hurd, 2014-01-03
+
+ <teythoon> hmpf, the hurd bootstrapping process is complicated and fragile,
+ maybe to the point that it is to be considered broken
+ <teythoon> aiui the hurd uses the filesystem for service lookup
+ <teythoon> older mach documentation suggests that there once existed a name
+ server instead for this purpose
+ <teythoon> the hurd approach is elegant and plan9ish
+ <teythoon> the problem is in the early bootstrapping
+ <teythoon> what if the root filesystem is r/o and there is no /servers or
+ /servers/exec ?
+ <teythoon> e. g. rm /servers/exec && reboot -> the rootfs dies early in the
+ hurd server bootstrap :/
+ <braunr> well yes
+ <braunr> it's normal to have such constraints
+ <teythoon> uh no
+ <braunr> at the same time, the boot protocol must be improved, if only to
+ support userspace disk drivers
+ <teythoon> totally unacceptable
+ <braunr> why not ?
+ <teythoon> b/c my box just died and lost it's exec node
+ <braunr> so ?
+ <braunr> loosing the exec node is unacceptable
+ <youpi> well, linux dies too if you don't have /dev populated at least a
+ bit
+ <braunr> not being able to boot without the "exec" service is pretty normal
+ <braunr> the hurd turns the vfs into a service directory
+ <teythoon> the exec service is there, only the lookup mechanism is broken
+ <braunr> replacing the name server you mentioned earlier
+ <teythoon> yes
+ <braunr> if you don't have services, you don't have them
+ <braunr> i don't see the problem
+ <braunr> the problem is the lookup mechanism getting broken
+ <teythoon> ... that easily
+ <braunr> imagine a boot protocol based on a ramfs filled from a cpio
+ <teythoon> i do actually ;)
+ <braunr> there would be no reason at all the lookup mechanism would break
+ <teythoon> yes
+ <teythoon> but the current situation is not acceptable
+ <braunr> i agree
+ <teythoon> ^^
+ <braunr> ext2fs is too unreliable for that
+ <braunr> but using the VFS as a directory is more than acceptable
+ <braunr> it's probably the main hurd feature
+ <teythoon> yes
+ <braunr> i see it rather as a circular dependency problem
+ <braunr> and if you have good ideas, i'm all ear for propel ... :>
+ <braunr> antrik already talked about some of them for the bootstrap
+ protocol
+ <braunr> we should sum them up somewhere if not done already
+ <teythoon> i've been pondering how to install a tmpfs translator as root
+ translator
+ <teythoon> braunr: we could create a special translator for /servers
+ <braunr> maybe
+ <teythoon> very much like fakeroot, it just proxies messages to a real
+ translator
+ <teythoon> but if operations like settrans fail, we handle them
+ transparently, like an overlay
+ <braunr> i consider /servers to be very close to /dev
+ <teythoon> yes
+ <braunr> so something like devfs seems obvious yes
+ <braunr> i don't even think there needs to be an overlay
+ <teythoon> y not ?
+ <braunr> why does /servers need real nodes ?
+ <teythoon> for persistence
+ <braunr> what for ?
+ <teythoon> e.g. crash server selection
+ <braunr> hm ok
+ <teythoon> network configuration
+ <braunr> i personally wouldn't make that persistent
+ <braunr> it can be configured in files and installed at boot time
+ <teythoon> me neither, but that's how it's currently done
+ <braunr> are you planning to actually work on that soon ?
+ <teythoon> if we need no persistence, we can just use tmpfs
+ <braunr> it wouldn't be a mere tmpfs
+ <teythoon> it could
+ <braunr> it's a tmpfs that performs automatic discovery and registration of
+ system services
+ <teythoon> with some special wrapper that preserves e.g. /servers/exec
+ <teythoon> oh
+ <braunr> so rather, devtmpfs
+ <teythoon> it is o_O :p
+ <braunr> ?
+ <braunr> what is what ?
+ <teythoon> well, it could be a tmpfs and some utility creating the nodes
+ <braunr> whether the node management is merged in or separate doesn't
+ matter that much i guess
+ <braunr> i'd personally imagine it merged, and tmpfs available as a
+ library, so that stuff like sysfs or netstatfs can easily be written
+
+
+## IRC, freenode, #hurd, 2014-02-12
+
+ <teythoon> braunr: i fixed all fsys-related receiver lookups in libdiskfs
+ and surely enough the bootstrap hangs with no indication whats wrong
+ <braunr> teythoon: use mach_print :/
+ <teythoon> braunr: the hurd bootstrap is both fragile and hard to tweak in
+ interesting ways :/
+ <braunr> teythoon: i agree with that
+ <braunr> teythoon: maybe this will help :
+ http://wiki.hurdfr.org/upload/graphviz/dot9b65733655309d059dca236f940ef37a.png
+ <braunr> although i guess you probably already know that
+ <teythoon> heh, unicode for the win >,<
+ <braunr> :/
+
+
+# Source Code Documentation
+
+Provide a cross-linked sources documentation, including generated files, like
+RPC stubs.
+
+ * <http://www.gnu.org/software/global/>
+
+
+# [[Hurd_101]]
+
+
+# [[hurd/IO_path]]
+
+Need more stuff like that.
+
+
+# IRC, freenode, #hurd, 2011-10-18
+
+ <frhodes> what happens @ boot. and which translators are started in what
+ order?
+ <antrik> short version: grub loads mach, ext2, and ld.so/exec; mach starts
+ ext2; ext2 starts exec; ext2 execs a few other servers; ext2 execs
+ init. from there on, it's just standard UNIX stuff
+
+
+# IRC, OFTC, #debian-hurd, 2011-11-02
+
+ <sekon_> is __dir_lookup a RPC ??
+ <sekon_> where can i find the source of __dir_lookup ??
+ <sekon_> grepping most gives out rvalue assignments
+ <sekon_> -assignments
+ <sekon_> but in hurs/fs.h it is used as a function ??
+ <pinotree> it should be the mig-generated function for that rpc
+ <sekon_> how do i know how its implemented ??
+ <sekon_> is there any way to delve deeprer into mig-generated functions
+ <tschwinge> sekon_: The MIG-generated stuff will either be found in the
+ package's build directory (if it's building it for themselves), or in the
+ glibc build directory (libhurduser, libmachuser; which are all the
+ available user RPC stubs).
+ <tschwinge> sekon_: The implementation can be found in the various Hurd
+ servers/libraries.
+ <tschwinge> sekon_: For example, [hurd]/libdiskfs/dir-lookup.c.
+ <tschwinge> sekon_: What MIG does is provide a function call interface for
+ these ``functions'', and the Mach microkernel then dispatches the
+ invocation to the corresponding server, for example a /hurd/ext2fs file
+ system (via libdiskfs).
+ <tschwinge> sekon_: This may help a bit:
+ http://www.gnu.org/software/hurd/hurd/hurd_hacking_guide.html
+
+
+# IRC, freenode, #hurd, 2012-01-08
+
+ <abique> can you tell me how is done in hurd: "ls | grep x" ?
+ <abique> in bash
+ <youpi> ls's standard output is a port to the pflocal server, and grep x's
+ standard input is a port to the pflocal server
+ <youpi> the connexion between both ports inside the pflocal server being
+ done by bash when it calls pipe()
+ <abique> youpi, so STDOUT_FILENO, STDIN_FILENO, STDERR_FILENO still exists
+ ?
+ <youpi> sure, hurd is compatible with posix
+ <abique> so bash 1) creates T1 (ls) and T2 (grep), then create a pipe at
+ the pflocal server, then connects both ends to T1 and T2, then start(T1),
+ start(T2) ?
+ <youpi> not exactly
+ <youpi> it's like on usual unix, bash creates the pipe before creating the
+ tasks
+ <youpi> then forks to create both of them, handling them each side of the
+ pipe
+ <abique> ok I see
+ <youpi> s/handling/handing/
+ <abique> but when you do pipe() on linux, it creates a kernel object, this
+ time it's 2 port on the pflocal ?
+ <youpi> yes
+ <abique> how are spawned tasks ?
+ <abique> with fork() ?
+ <youpi> yes
+ <youpi> which is just task_create() and duplicating the ports into the new
+ task
+ <abique> ok
+ <abique> so it's easy to rewrite fork() with a good control of duplicated
+ fd
+ <abique> about threading, mutexes, conditions, etc.. are kernel objects or
+ just userland objects ?
+ <youpi> just ports
+ <youpi> (only threads are kernel objects)
+ <abique> so, about efficiency, are pipes and mutexes efficient ?
+ <youpi> depends what you call "efficient"
+ <youpi> it's less efficient than on linux, for sure
+ <youpi> but enough for a workable system
+ <abique> maybe hurd is the right place for a userland thread library like
+ pth or any fiber library
+ <abique> ?
+ <youpi> hurd already uses a userland thread library
+ <youpi> libcthreads
+ <abique> is it M:N ?
+ <youpi> libthreads, actually
+ <youpi> yes
+
+Actually, the Hurd has never used an M:N model. Both libthreads (cthreads) and libpthread use an 1:1 model.
+
+ <abique> nice
+ <abique> is the task scheduler in the kernel ?
+ <youpi> the kernel thread scheduler, yes, of course
+ <youpi> there has to be one
+ <abique> are the posix open()/readdir()/etc... the direct vfs or wraps an
+ hurd layer libvfs ?
+ <youpi> they wrap RPCs to the filesystem servers
+ <antrik> the Bushnell paper is probably the closest we have to a high-level
+ documentation of these concepts...
+ <antrik> the Hurd does not have a central VFS component at all. name
+ lookups are performed directly on the individual FS servers
+ <antrik> that's probably the most fundamental design feature of the Hurd
+ <antrik> (all filesystem operations actually, not only lookups)
+
+
+## IRC, freenode, #hurd, 2012-01-09
+
+ <braunr> youpi: are you sure cthreads are M:N ? i'm almost sure they're 1:1
+ <braunr> and no modern OS is a right place for any thread userspace
+ library, as they wouldn't have support to run threads on different
+ processors (unless processors can be handled by userspace servers, but
+ still, it requires intimate cooperation between the threading library and
+ the kernel/userspace server in any case
+ <youpi> braunr: in libthreads, they are M:N
+ <youpi> you can run threads on different processors by using several kernel
+ threads, there's no problem in there, a lot of projects do this
+ <braunr> a pure userspace library can't use kernel threads
+ <braunr> at least pth was explacitely used on systems like bsd at a time
+ when they didn't have kernel threads exactly for that reason
+ <braunr> explicitely*
+ <braunr> and i'm actually quite surprised to learn that we have an M:N
+ threading model :/
+ <youpi> why do you say "can't" ?
+ <braunr> but i wanted to reply to abique and he's not around
+ <youpi> of course you need kernel threads
+ <youpi> but all you need is to bind them
+ <braunr> well, what i call a userspace threading library is a library that
+ completely implement threads without the support of the kernel
+ <braunr> or only limited support, like signals
+ <youpi> errr, you can't implement anything with absolutely no support of
+ the kernel
+ <braunr> pth used only SIGALRM iirc
+ <youpi> asking for more kernel threads to use more processors doesn't seem
+ much
+ <braunr> it's not
+ <braunr> but i'm refering to what abique said
+ <braunr> 01:32 < abique> maybe hurd is the right place for a userland
+ thread library like pth or any fiber library
+ <youpi> well, it's indeed more, because the glibc lets external libraries
+ provide their mutex
+ <youpi> while on linux, glibc doesn't
+ <braunr> i believe he meant removing thread support from the kernel :p
+ <youpi> ah
+ <braunr> and replying "nice" to an M:N threading model is also suspicious,
+ since experience seems to show 1:1 models are better
+ <youpi> "better" ????
+ <braunr> yes
+ <youpi> well
+ <youpi> I don't have any time to argue about that
+ <youpi> because that'd be extremely long
+ <braunr> simpler, so far less bugs, and also less headache concerning posix
+ conformance
+ <youpi> but there's no absolute "better" here
+ <youpi> but less performant
+ <youpi> less flexible
+ <braunr> that's why i mention experience :)
+ <youpi> I mean experience too
+ <braunr> why less performant ?
+ <youpi> because you pay kernel transition
+ <youpi> because you don't know anything about the application threads
+ <youpi> etc.
+ <braunr> really ?
+ <youpi> yes
+ <braunr> i fail to see where the overhead is
+ <youpi> I'm not saying m:n is generally better than 1:1 either
+ <youpi> thread switch, thread creation, etc.
+ <braunr> creation is slower, i agree, but i'm not sure it's used frequently
+ enough to really matter
+ <youpi> it is sometimes used frequently enough
+ <youpi> and in those cases it would be a headache to avoid it
+ <braunr> ok
+ <braunr> i thought thread pools were used in those cases
+ <youpi> synchronized with kernel mutexes ?
+ <youpi> that's still slow
+ <braunr> it reduces to the thread switch overhead
+ <braunr> which, i agree is slightly slower
+ <braunr> ok, i's a bit less performant :)
+ <braunr> well don't futexes exist just for that too ?
+ <youpi> yes and no
+ <youpi> in that case they don't help
+ <youpi> because they do sleep
+ <youpi> they help only when the threads are living
+ <braunr> ok
+ <youpi> now as I said I don't have to talk much more, I have to leave :)
+
+
+# IRC, freenode, #hurd, 2012-12-06
+
+ <braunr> spiderweb: have you read
+ http://www.gnu.org/software/hurd/hurd-paper.html ?
+ <spiderweb> I'll have a look.
+ <braunr> and also the beginning of
+ http://ftp.sceen.net/mach/mach_a_new_kernel_foundation_for_unix_development.pdf
+ <braunr> these two should provide a good look at the big picture the hurd
+ attemtps to achieve
+ <Tekk_> I can't help but wonder though, what advantages were really
+ achieved with early mach?
+ <Tekk_> weren't they just running a monolithic unix server like osx does?
+ <braunr> most mach-based systems were
+ <braunr> but thanks to that, they could provide advanced features over
+ other well established unix systems
+ <braunr> while also being compatible
+ <Tekk_> so basically it was just an ease of development thing
+ <braunr> well that's what mach aimed at being
+ <braunr> same for the hurd
+ <braunr> making things easy
+ <Tekk_> but as a side effect hurd actually delivers on the advantages of
+ microkernels aside from that, but the older systems wouldn't, correct?
+ <braunr> that's how there could be network file systems in very short time
+ and very scarce resources (i.e. developers working on it), while on other
+ systems it required a lot more to accomplish that
+ <braunr> no, it's not a side effect of the microkernel
+ <braunr> the hurd retains and extends the concept of flexibility introduced
+ by mach
+ <Tekk_> the improved stability, etc. isn't a side effect of being able to
+ restart generally thought of as system-critical processes?
+ <braunr> no
+ <braunr> you can't restart system critical processes on the hurd either
+ <braunr> that's one feature of minix, and they worked hard on it
+ <Tekk_> ah, okay. so that's currently just the domain of minix
+ <Tekk_> okay
+ <Tekk_> spiderweb: well, there's 1 advantage of minix for you :P
+ <braunr> the main idea of mach is to make it easy to extend unix
+ <braunr> without having hundreds of system calls
+
+[[/system_call]].
+
+ <braunr> the hurd keeps that and extends it by making many operations
+ unprivileged
+ <braunr> you don't need special code for kernel modules any more
+ <braunr> it's easy
+ <braunr> you don't need special code to handle suid bits and other ugly
+ similar hacks,
+ <braunr> it's easy
+ <braunr> you don't need fuse
+ <braunr> easy
+ <braunr> etc..
+
+
+# Service Directory
+
+## IRC, freenode, #hurd, 2012-12-06
+
+ <spiderweb> what is the #1 feature that distinguished hurd from other
+ operating systems. the concept of translators. (will read more when I get
+ more time).
+ <braunr> yes, translators
+ <braunr> using the VFS as a service directory
+ <braunr> and the VFS permissions to control access to those services
+
+
+## IRC, freenode, #hurd, 2013-05-23
+
+ <gnu_srs> Hi, is there any efficient way to control which backed
+ translators are called via RPC with a user space program?
+ <gnu_srs> Take for example io_stat: S_io_stat is defined in boot/boot.c,
+ pfinet/io-ops.c and pflocal/io.c
+ <gnu_srs> And the we have libdiskfs/io-stat.c:diskfs_S_io_stat,
+ libnetfs/io-stat.c:netfs_S_io_stat, libtreefs/s-io.c:treefs_S_io_stat,
+ libtrivfs/io-stat.c:trivfs_S_io_stat
+ <gnu_srs> How are they related?
+ <braunr> gnu_srs: it depends on the server (translator) managing the files
+ (nodes) you're accessing
+ <braunr> so use fsysopts to know the server, and see what this server uses
+ <gnu_srs> fsysopts /hurd/pfinet and fsysopts /hurd/pflocal gives the same
+ answer: ext2fs --writable --no-inherit-dir-group --store-type=typed
+ device:hd0s1
+ <braunr> of course
+ <braunr> the binaries are regular files
+ <braunr> see /servers/socket/1 and /servers/socket/2 instead
+ <braunr> which are the nodes representing the *service*
+ <braunr> again, the hurd uses the file system as a service directory
+ <braunr> this usage of the file system is at the core of the hurd design
+ <braunr> files are not mere files, they're service names
+ <braunr> it happens that, for most files, the service behind them is the
+ same as for regular files
+ <braunr> gnu_srs: this *must* be obvious for you to do any tricky work on
+ the hurd
+
+ <gnu_srs> Anyway, if I create a test program calling io_stat I assume
+ S_io_stat in pflocal is called.
+ <gnu_srs> How to make the program call S_io_stat in pfinet instead?
+ <braunr> create a socket managed by pfinet
+ <braunr> i.e. an inet or inet6 socket
+ <braunr> you can't assume io_stat is serviced by pflocal
+ <braunr> only stats on unix sockets of pipes will be
+ <braunr> or*
+ <gnu_srs> thanks, what about the *_S_io_stat functions?
+ <braunr> what about them ?
+ <gnu_srs> How they fit into the picture, e.g. diskfs_io_stat?
+ <gnu_srs> *diskfs_S_io_stat
+ <braunr> gnu_srs: if you open a file managed by a server using libdiskfs,
+ e.g. ext2fs, that one will be called
+ <gnu_srs> Using the same user space call: io_stat, right?
+ <braunr> it's all userspace
+ <braunr> say rather, client-side
+ <braunr> the client calls the posix stat() function, which is implemented
+ by glibc, which converts it into a call to io_stat, and sends it to the
+ server managing the open file
+ <braunr> the io_stat can change depending on the server
+ <braunr> the remote io_stat implementation, i mean
+ <braunr> identify the server, and you will identify the actual
+ implementation
+
+
+## IRC, freenode, #hurd, 2013-06-30
+
+ <hacklu> hi, what is the replacer of netname_check_in?
+
+ <hacklu> I want to ask another question. in my opinion, the rpc is the
+ mach's way, and the translator is the hurd's way. so somebody want to
+ lookup a service, it should not need to ask the mach kernel know about
+ this query. the hurd will take the control.
+ <hacklu> am I right?
+ <braunr> no
+ <braunr> that's nonsense
+ <braunr> service lookups has never been in mach
+ <braunr> first mach based systems used a service directory, whereas the
+ hurd uses the file system for that
+ <braunr> you still need mach to communicate with either of those
+ <hacklu> how to understand the term of service directory here?
+ <braunr> a server everyone knows
+ <braunr> which gives references to other servers
+ <braunr> usually, depending on the name
+ <braunr> e.g. name_lookup("net") -> port right to network server
+ <hacklu> is that people use netname_check_in to register service in the
+ past? now used libtrivfs?
+ <braunr> i don't know about netname_check_in
+ <braunr> old mach (not gnumach) documentation might mention this service
+ directory
+ <braunr> libtrivfs doesn't have much to do with that
+ <braunr> on the hurd, the equivalent is the file system
+ <hacklu> maybe that is outdate, I just found that exist old doc, and old
+ code which can't be build.
+ <braunr> every process knows /
+ <braunr> the file system is the service directory
+ <braunr> nodes refer to services
+ <hacklu> so the file system is the nameserver, any new service should
+ register in it before other can use
+ <braunr> and the file system is distributed, so looking up a service may
+ require several queries
+ <braunr> setting a translator is exactly that, registering a program to
+ service requests on a node
+ <braunr> the file system isn't one server though
+ <braunr> programs all know about /, but then, lookups are recursive
+ <braunr> e.g. if you have / and /home, and are looking for
+ /home/hacklu/.profile, you ask / which tells you about /home, and /home
+ will give you a right to /home/hacklu/.profile
+ <hacklu> even in the past, the mach don't provide name register service,
+ there must be an other server to provide this service?
+ <braunr> yes
+ <braunr> what's nonsense in your sentence is comparing RPCs and translators
+ <braunr> translators are merely servers attached to the file system, using
+ RPCs to communicate with the rest of the system
+ <hacklu> I know yet, the two just one thing.
+ <braunr> no
+ <braunr> two things :p
+ <braunr> completely different and unrelated except for one using the other
+ <hacklu> ah, just one used aonther one.
+ <hacklu> is exist anyway to anounce service except settrans with file node?
+ <braunr> more or less
+ <braunr> tasks can have special ports
+ <braunr> that's how one task knows about / for example
+ <braunr> at task creation, a right to / is inserted in the new task
+ <hacklu> I think this is also a file node way.
+ <braunr> no
+ <braunr> if i'm right, auth is referenced the same way
+ <braunr> and there is no node for auth
+ <hacklu> how the user get the port of auth with node?
+ <braunr> it's given when a task is created
+ <hacklu> pre-set in the creation of one task?
+ <braunr> i'm unconfortable with "pre-set"
+ <braunr> inserted at creation time
+ <braunr> auth is started very early
+ <braunr> then tasks are given a reference to it
+
+
+# IRC, freenode, #hurd, 2012-12-10
+
+ <spiderweb> I want to work on hurd, but I think I'm going to start with
+ minix, I own the minix book 3rd ed. it seems like a good intro to
+ operating systems in general. like I don't even know what a semaphore is
+ yet.
+ <braunr> well, enjoy learning :)
+ <spiderweb> once I finish that book, what reading do you guys recommend?
+ <spiderweb> other than the wiki
+ <braunr> i wouldn't recommend starting with a book that focuses on one
+ operating system anyway
+ <braunr> you tend to think in terms of what is done in that specific
+ implementation and compare everything else to that
+ <braunr> tannenbaum is not only the main author or minix, but also the one
+ of the book http://en.wikipedia.org/wiki/Modern_Operating_Systems
+ <braunr>
+ http://en.wikipedia.org/wiki/List_of_important_publications_in_computer_science#Operating_systems
+ should be a pretty good list :)
+
+
+# IRC, freenode, #hurd, 2013-03-12
+
+ <mjjc> i have a question regarding ipc in hurd. if a task is created, does
+ it contain any default port rights in its space? i am trying to deduce
+ how one calls dir_lookup() on the root translator in glibc's open().
+ <kilobug> mjjc: yes, there are some default port rights, but I don't
+ remember the details :/
+ <mjjc> kilobug: do you know where i should search for details?
+ <kilobug> mjjc: hum either in the Hurd's hacking guide
+ https://www.gnu.org/software/hurd/hacking-guide/ or directly in the
+ source code of exec server/libc I would say, or just ask again the
+ question here later on to see if someone else has more information
+ <mjjc> ok, thanks
+ <pinotree> there's also rpctrace to, as the name says, trace all the rpc's
+ executed
+ <braunr> some ports are introduced in new tasks, yes
+ <braunr> see
+ http://www.gnu.org/software/hurd/hacking-guide/hhg.html#The-main-function
+ <braunr> and
+ <braunr>
+ http://www.gnu.org/software/hurd/gnumach-doc/Task-Special-Ports.html#Task-Special-Ports
+ <mjjc> yes, the second link was just what i was looking for, thanks
+ <braunr> the second is very general
+ <braunr> also, the first applies to translators only
+ <braunr> if you're looking for how to do it for a non-translator
+ application, the answer is probably somewhere in glibc
+ <braunr> _hurd_startup i'd guess
+
+
+# IRC, freenode, #hurd, 2013-06-15
+
+ <damo22> ive been reading a little about exokernels or unikernels, and i
+ was wondering if it might be relevant to the GNU/hurd design. I'm not
+ too familiar with hurd terminology so forgive me. what if every
+ privileged service was compiled as its own mini "kernel" that handled (a)
+ any hardware related to that service (b) any device nodes exposed by that
+ service etc...
+ <braunr> yes but not really that way
+ <damo22> under the current hurd model of the operating system, how would
+ you talk to hardware that required specific timings like sound hardware?
+ <braunr> through mapped memory
+ <damo22> is there such a thing as an interrupt request in hurd?
+ <braunr> obviously
+ <damo22> ok
+ <damo22> is there any documentation i can read that involves a driver that
+ uses irqs for hurd?
+ <braunr> you can read the netdde code
+ <braunr> dde being another project, there may be documentation about it
+ <braunr> somewhere else
+ <braunr> i don't know where
+ <damo22> thanks
+ <damo22> i read a little about dde, apparently it reuses existing code from
+ linux or bsd by reimplementing parts of the old kernel like an api or
+ something
+ <braunr> yes
+ <damo22> it must translate these system calls into ipc or something
+ <damo22> then mach handles it?
+ <braunr> exactly
+
+[[/system_call]].
+
+ <braunr> that's why i say it's not the exokernel way of doing things
+ <damo22> ok
+ <damo22> so does every low level hardware access go through mach?'
+ <braunr> yes
+ <braunr> well no
+ <braunr> interrupts do
+ <braunr> ports (on x86)
+ <braunr> everything else should be doable through mapped memory
+ <damo22> seems surprising that the code for it is so small
+ <braunr> 1/ why surprising ? and 2/ "so small" ?
+ <damo22> its like the core of the OS, and yet its tiny compared to say the
+ linux kernel
+ <braunr> it's a microkenrel
+ <braunr> well, rather an hybrid
+ <braunr> the size of the equivalent code in linux is about the same
+ <damo22> ok
+ <damo22> with the model that privileged instructions get moved to
+ userspace, how does one draw the line between what is OS and what is user
+ code
+ <braunr> privileged instructions remain in the kernel
+ <braunr> that's one of the few responsibilities of the kernel
+ <damo22> i see, so it is an illusion that the user has privilege in a sense
+ <braunr> hum no
+ <braunr> or, define "illusion"
+ <damo22> well the user can suddenly do things never imaginable in linux
+ <damo22> that would have required sudo
+ <braunr> yes
+ <braunr> well, they're not unimaginable on linux
+ <braunr> it's just not how it's meant to work
+ <damo22> :)
+ <braunr> and why things like fuse are so slow
+ <braunr> i still don't get "i see, so it is an illusion that the user has
+ privilege in a sense"
+ <damo22> because the user doesnt actually have the elevated privilege its
+ the server thing (translator)?
+ <braunr> it does
+ <braunr> not at the hardware level, but at the system level
+ <braunr> not being able to do it directly doesn't mean you can't do it
+ <damo22> right
+ <braunr> it means you need indirections
+ <braunr> that's what the kernel provides
+ <damo22> so the user cant do stuff like outb 0x13, 0x1
+ <braunr> he can
+ <braunr> he also can on linux
+ <damo22> oh
+ <braunr> that's an x86 specifity though
+ <damo22> but the user would need hardware privilege to do that
+ <braunr> no
+ <damo22> or some kind of privilege
+ <braunr> there is a permission bitmap in the TSS that allows userspace to
+ directly access some ports
+ <braunr> but that's really x86 specific, again
+ <damo22> i was using it as an example
+ <damo22> i mean you wouldnt want userspace to directly access everything
+ <braunr> yes
+ <braunr> the only problem with that is dma reall
+ <braunr> y
+ <braunr> because dma usually access physical memory directly
+ <damo22> are you saying its good to let userspace access everything minus
+ dma?
+ <braunr> otherwise you can just centralize permissions in one place (the
+ kernel or an I/O server for example)
+ <braunr> no
+ <braunr> you don't let userspace access everything
+ <damo22> ah
+ <damo22> yes
+ <braunr> userspace asks for permission to access one specific part (a
+ memory range through mapping)
+ <braunr> and can't access the rest (except through dma)
+ <damo22> except through dma?? doesnt that pose a large security threat?
+ <braunr> no
+ <braunr> you don't give away dma access to anyone
+ <braunr> only drivers
+ <damo22> ahh
+ <braunr> and drivers are normally privileged applications anyway
+ <damo22> so a driver runs in userspace?
+ <braunr> so the only effect is that bugs can affect other address spaces
+ indirectly
+ <braunr> netdde does
+ <damo22> interesting
+ <braunr> and they all should but that's not the case for historical reasons
+ <damo22> i want to port ALSA to hurd userspace :D
+ <braunr> that's not so simple unfortunately
+ <braunr> one of the reasons it's hard is that pci access needs arbitration
+ <braunr> and we don't have that yet
+ <damo22> i imagine that would be difficult
+ <braunr> yes
+ <braunr> also we're not sure we want alsa
+ <braunr> alsa drivers, maybe, but probably not the interface itself
+ <damo22> its tangled spaghetti
+ <damo22> but the guy who wrote JACK for audio hates OSS, and believes it is
+ rubbish due to the fact it tries to read and write to a pcm device node
+ like a filesystem with no care for timing
+ <braunr> i don't know audio well enough to tell you anything about that
+ <braunr> was that about oss3 or oss4 ?
+ <braunr> also, the hurd isn't a real time system
+ <braunr> so we don't really care about timings
+ <braunr> but with "good enough" latencies, it shouldn't be a problem
+ <damo22> but if the audio doesnt reach the sound card in time, you will get
+ a crackle or a pop or a pause in the signal
+ <braunr> yep
+ <braunr> it happens on linux too when the system gets some load
+ <damo22> some users find this unnacceptable
+ <braunr> some users want real time systems
+ <braunr> using soft real time is usually plenty enough to "solve" this kind
+ of problems
+ <damo22> will hurd ever be a real time system?
+ <braunr> no idea
+ <youpi> if somebody works on it why not
+ <youpi> it's the same as linux
+ <braunr> it should certainly be simpler than on linux though
+ <damo22> hmm
+ <braunr> microkernels are well suited for real time because of the well
+ defined interfaces they provide and the small amount of code running in
+ kernel
+ <damo22> that sounds promising
+ <braunr> you usually need to add priority inheritance and take care of just
+ a few corner cases and that's all
+ <braunr> but as youpi said, it still requires work
+ <braunr> and nobody's working on it
+ <braunr> you may want to check l4 fiasco.oc though
+
+
+# System Personality
+
+## IRC, freenode, #hurd, 2013-07-29
+
+ <teythoon> over the past few days I gained a new understanding of the Hurd
+ <braunr> teythoon: really ? :)
+ <tschwinge> teythoon: That it's a complex and distributed system? ;-)
+ <tschwinge> And at the same time a really simple one?
+ <tschwinge> ;-D
+ <teythoon> it's just a bunch of mach programs and some do communicate and
+ behave in a way a posix system would, but that is more a convention than
+ anything else
+ <teythoon> tschwinge: yes, kind of simple and complex :)
+ <braunr> the right terminology is "system personality"
+ <braunr> 11:03 < teythoon> over the past few days I gained a new
+ understanding of the Hurd
+ <braunr> teythoon: still no answer on that :)
+ <teythoon> braunr: ah, I spent lot's of time with the core servers and
+ early bootstrapping and now I gained the feeling that I've seen the Hurd
+ for what it really is for the first time
+
+
+# RPC Interfaces
+
+## IRC, freenode, #hurd, 2013-09-03
+
+ <rekado> I'm a little confused by the hurd and incubator git repos.
+ <rekado> DDE is only found in the dde branch in incubator, but not in the
+ hurd repo.
+ <rekado> Does this mean that DDE is not ready for master yet?
+ <braunr> yes
+ <rekado> If DDE is not yet used in the hurd (except in the dde branch in
+ the incubator repo), does pfinet use some custom glue code to use the
+ Linux drivers?
+ <braunr> this has nothing to do with pfinet
+ <braunr> pfinet is the networking stack, netdde are the networking drivers
+ <braunr> the interface between them doesn't change, whether drivers are in
+ kernel or not
+ <rekado> I see
+
+
+# IRC, freenode, #hurd, 2013-09-20
+
+ <giuscri> HI there, I have no previous knowledge about OS's. I'm trying to
+ undestand the structure of the Hurd and the comparison between, say,
+ Linux way of managing stuff ...
+ <giuscri> for instance, I read: "Unlike other popular kernel software, the
+ Hurd has an object-oriented structure that allows it to evolve without
+ compromising its design."
+ <giuscri> that means that while for adding feature to the Linux-kernel you
+ have to add some stuff `inside` a procedure, whilst in the Hurd kernel
+ you can just, in principle at least, add an object and making the kernel
+ using it?...
+ <giuscri> Am I making stuff too simple?
+ <giuscri> Thanks
+ <braunr> not exactly
+ <braunr> unix historically has a "file-oriented" structure
+ <braunr> the hurd allows servers to implement whatever type they want,
+ through the ability to create custom interfaces
+ <braunr> custom interfaces means custom calls, custom semantics, custom
+ methods on objects
+ <braunr> you're not restricted to the set of file interfaces (open, seek,
+ read, write, select, close, etc..) that unix normally provides
+ <giuscri> braunr: uhm ...some example?
+ <braunr> see processes for example
+ <braunr> see
+ http://darnassus.sceen.net/gitweb/savannah_mirror/hurd.git/tree/HEAD:/hurd
+ <braunr> this is the collection of interfaces the hurd provides
+ <braunr> most of them map to unix calls, because gnu aims at posix
+ compatibility too
+ <braunr> some are internal, like processes
+ <braunr> or authentication
+ <braunr> but most importantly, you're not restricted to that, you can add
+ your own interfaces
+ <braunr> on a unix, you'd need new system calls
+ <braunr> or worse, extending through the catch-all ioctl call
+ <giuscri> braunr: mhn ...sorry, not getting that.
+ <braunr> what part ?
+ <kilobug> ioctl has become such a mess :s
+ <giuscri> braunr: when you say that Unix is `file-oriented` you're
+ referring to the fact that sending/receiving data to/from the kernel is
+ designed like sending/receiving data to/from a file ...?
+ <braunr> not merely sending/receiving
+ <braunr> note how formatted your way of thinking is
+ <braunr> you directly think in terms of sending/receiving (i.e. read and
+ write)
+ <giuscri> braunr: (yes)
+ <braunr> that's why unix is file oriented, access to objects is done that
+ way
+ <braunr> on the hurd, the file interface is one interface
+ <braunr> there is nothing preventing you from implementing services with a
+ different interface
+ <braunr> as a real world example, people interested in low latency
+ profesionnal audio usually dislike send/recv
+ <braunr> see
+ http://lac.linuxaudio.org/2003/zkm/slides/paul_davis-jack/unix.html for
+ example
+ <kilobug> braunr: how big and messy ioctl has become is a good proof that
+ the Unix way, while powerful, does have its limits
+ <braunr> giuscri: keep in mind the main goal of the hurd is extensibility
+ without special privileges
+ <giuscri> braunr: privileges?
+ <braunr> root
+ <giuscri> braunr: what's wrong with privileges?
+ <braunr> they allow malicious/buggy stuff to happne
+ <braunr> and have dramatic effects
+ <giuscri> braunr: you're obviously *not* referring to the fact that once
+ one have the root privileges could change some critical-data
+ <giuscri> ?
+ <braunr> i'm referring to why privilege separation exists in the first
+ place
+ <braunr> if you have unprivileged users, that's because you don't want them
+ to mess things up
+ <braunr> on unix, extending the system requires privileges, giving those
+ who do it the ability to destroy everything
+ <giuscri> braunr: yes, I think the same
+ <braunr> the hurd is designed to allow unprivileged users to extend their
+ part of the system, and to some extent share that with other users
+ <braunr> although work still remains to completely achieve that
+ <giuscri> braunr: mhn ...that's the `server`-layer between the
+ single-application and kernel ?
+ <braunr> the multi-server based approach not only allows that, but
+ mitigates damage even when privileged servers misbehave
+ <braunr> one aspect of it yes
+ <braunr> but as i was just saying, even root servers can't mess things too
+ much
+ <braunr> for example, our old (sometimes buggy) networking stack can be
+ restarted when it behaves wrong
+ <braunr> the only side effect being some applications (ssh and exim come to
+ mind) which need to be restarted too because they don't expect the
+ network stack to be restarted
+ <giuscri> braunr: ...instead?
+ <braunr> ?
+ <kilobug> giuscri: on Linux, if the network stack crash/freezes, you don't
+ have any other option than rebooting the system - usually with a nice
+ "kernel pani"
+ <kilobug> giuscri: and you may even get filesystem corruption "for free" in
+ the bundle
+ <braunr> and hoping it didn't corrupt something important like file system
+ caches before being flushed
+ <giuscri> kilobug, braunr : mhn, ook
+
+
+# IRC, freenode, #hurd, 2013-10-13
+
+ <ahungry> ahh, ^c isn't working to cancel a ping - is there alternative?
+ <braunr> ahungry: ctrl-c does work, you just missed something somewhere and
+ are running a shell directly on a console, without a terminal to handle
+ signals
+
+
+# IRC, freenode, #hurd, 2013-11-04
+
+ <braunr> nalaginrut: you can't use the hurd for real embedded stuff without
+ a lot of work on it
+ <braunr> but the hurd design applies very well to embedded environments
+ <braunr> the fact that we're able to dynamically link practically all hurd
+ servers against the c library can visibly reduce the system code size
+ <braunr> it also reduces the TCB
+ <nalaginrut> what about the memory occupation?
+ <braunr> code size is about memory occupation
+ <teythoon> also, the system is composable like lego, don't need tcp - don't
+ include pfinet then
+ <braunr> the memory overheald of a capability based system like the hurd
+ are, well, capabilities
+ <braunr> teythoon: that's not an argument compared to modular kernels like
+ linux
+ <teythoon> yes it is
+ <braunr> why ?
+ <braunr> if you don't need tcp in linux, you just don't load it
+ <braunr> same thing
+ <teythoon> ok, right
+ <braunr> on the other hand, a traditional unix kernel can never be linked
+ against the c library
+ <braunr> much less dynamically
+ <teythoon> right
+ <nalaginrut> I think the point is that it's easy to cut, since it has
+ better modularity than monolithic, and could be done in userland relative
+ easier
+ <braunr> modularity isn't better
+ <braunr> that's a big misconception
+ <teythoon> also, restarting components is easier on a distributed system
+ <braunr> on the hurd, this is a side effect
+ <braunr> and it doesn't apply well
+ <nalaginrut> braunr: oops, misconception
+ <braunr> many core servers such as proc, auth, exec, the root fs server
+ can't be restarted at all
+ <teythoon> not yet
+ <braunr> and servers like pfinet can be restarted, but at the cost of posix
+ servers not expecting that
+ <braunr> looping on errors such as EBADF because the target socket doesn't
+ exist any more
+ <teythoon> I've been working on a restartable exec server during some of my
+ gsoc weekends
+ <braunr> ah right
+ <braunr> linux has kexec
+ <braunr> and can be patched at run time
+ <nalaginrut> sounds like Hurd needs something similar to generalizable
+ continuation
+ <braunr> so again, it's not a real advantage
+ <braunr> no
+ <nalaginrut> sorry serilizable
+ <braunr> that would persistence
+ <braunr> personally, i don't want it at all
+ <teythoon> yes it is a real advantage, b/c the means of communication
+ (ports) is common to every IPC method on Hurd, and ports are first class
+ objects
+ <teythoon> so preserving the state is much easier on Hurd
+ <braunr> if a monolithic kernel can do it too, it's not a real advantage
+ <teythoon> yes, but it is more work
+ <braunr> that is one true advantage of the hurd
+ <braunr> but don't reuse it each time
+ <nalaginrut> oh, that's nice for the ports
+ <teythoon> why not?
+ <braunr> what we're talking about here is resilience
+ <braunr> the fact that it's easier to implement doesn't mean the hurd is
+ better because it has resilience
+ <braunr> it simply means the hurd is better because it's easier to
+ implement things on it
+ <braunr> same for development in general
+ <braunr> debugging
+ <braunr> virtualization
+ <braunr> etc..
+ <nalaginrut> yes, but why we stick to compare it to monolithic
+ <braunr> but it's still *one* property
+ <teythoon> well, minix advertises this feature a lot, even if minix can
+ only restart very simple things like printer servers
+ <braunr> minix sucks
+ <braunr> let them advertise what they can
+ <teythoon> ^^
+ <nalaginrut> it has cool features, that's enough, no need to find a feature
+ that monolithic can never done
+ <braunr> no it's not enough
+ <braunr> minix isn't a general purpose system
+ <braunr> let's just not compare it to general purpose systems
+
+
+# IRC, freenode, #hurd, 2013-11-08
+
+ <teythoon> and, provided you have suitable language bindings, you can
+ replace almost any hurd server with your own implementation in any
+ language
+ <crocket> teythoon: language bindings?
+ <crocket> Do you mean language bindings against C libraries?
+ <teythoon> either that or for the low level mach primitives
+ <crocket> For your information, IPC is independent of languages.
+ <teythoon> sure, that's the beauty
+ <crocket> Why is hurd best for replacing parts written in C with other
+ languages?
+ <teythoon> because Hurd consists of many servers, each server managing one
+ kind of resource
+ <teythoon> so you have /hurd/proc managing posix processes
+ <teythoon> you could reimplement /hurd/proc in say python or go, and
+ replace just that component of the Hurd system
+ <teythoon> you cannot do this with any other (general purpose) operating
+ system that I know of
+ <teythoon> you could incrementally replace the Hurd with your own
+ Hurd-compatible set of servers written in X
+ <teythoon> use a language that you can verify, i.e. prove that a certain
+ specification is fulfilled, and you end up with an awesome stable and
+ secure operating system
+ <crocket> Any microkernel OS fits the description.
+ <crocket> teythoon, Does hurd have formal protocols for IPC communications?
+ <teythoon> sure, name some other general purpose and somewhat
+ posix-compatible microkernel based operating system please
+ <teythoon> what do you mean by formal protocols ?
+ <crocket> IPC communications need to be defined in documents.
+ <teythoon> the "wire" format is specified of course, the semantic not so
+ much
+ <crocket> network protocols exist.
+ <crocket> HTTP is a transport protocol.
+ <crocket> Without formal protocols, IPC communications suffer from
+ debugging difficulties.
+ <crocket> Formal protocols make it possible to develop and test each module
+ independently.
+ <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
+ <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
+ be considered as a formal protocol.
+ <crocket> However, the file server protocol should be defined on top of IPC
+ protocol.
+ <teythoon> the file server protocol is in fs.defs
+ <teythoon> every protocol spoken is defined in that ipc description
+ language
+ <teythoon> it is used to derive code from
+ <braunr> crocket: not any system can be used to implement system services
+ in any language
+ <braunr> in theory, they do, but in theory only
+ <braunr> the main reason they don't is because most aren't posix compliant
+ from the ground up
+ <braunr> posix compliance is achieved through virtualization
+ <braunr> which isolates services too much for them to get useful,
+ notwithstanding the impacts on performance, memory, etc..
+ <crocket> braunr, Do you mean it's difficult to achieve POSIX compliance
+ with haskell?
+ <braunr> crocket: i mean most l4 based systems aren't posix
+ <braunr> genode isn't posix
+ <braunr> helenos is by design not posix
+ <braunr> the hurd is the only multi server system providing such a good
+ level of posix conformance
+ <braunr> and with tls on the way, we'll support even more non-posix
+ applications that are nonetheless very common on unices because of
+ historical interfaces still present, such as mcontext
+ <braunr> and modern ones
+ <braunr> e.g. ruby is now working, go should be there after tls
+ * teythoon drools over the perspective of having go on the Hurd...
+ <crocket> braunr, Is posix relevant now?
+ <braunr> it's hugely relevant
+ <braunr> conforming to posix and some native unix interfaces is the only
+ way to reuse a lot of existing production applications
+ <braunr> and for the matter at hand (system services not written in c), it
+ means almost readily getting runtimes for other languages than c
+ <braunr> something other microkernel based system will not have
+ <braunr> imagine this
+ <braunr> one day, one of us could create a company for a hurd-like system,
+ presenting this idea as the killer feature
+ <braunr> by supporting posix, customers could port their software with very
+ little effort
+ <braunr> *very little effort* is what makes software attractive
+ <crocket>
+ http://stackoverflow.com/questions/1806585/why-is-linux-called-a-monolithic-kernel/1806597#1806597
+ says "The disadvantage to a microkernel is that asynchronous IPC
+ messaging can become very difficult to debug, especially if fibrils are
+ implemented."
+ <crocket> " GNU Hurd suffers from these debugging problems (reference)."
+ <braunr> stackoverflow is usually a nice place
+ <braunr> but concerning microkernel stuff, you'll read a lot of crap
+ anywhere
+ <braunr> whether it's sync or async, tracking references is a hard task
+ <braunr> it's a bit more difficult in distributed systems, but not that
+ much if the proper debugging features are provided
+ <braunr> we actually don't suffer from that too much
+ <braunr> many of us have been able to debug reference leaks in the past,
+ without too much trouble
+ <braunr> we lack some tools that would give us a better view of the system
+ state
+ <crocket> braunr, But is it more difficult with microkernel?
+ <braunr> crocket: it's more difficult with distributed systems
+ <crocket> How much more difficult?
+ <braunr> i don't know
+ <crocket> distributed systems
+ <braunr> not much
+ <crocket> braunr, How do you define distributed systems?
+ <braunr> crocket: not monolithic
+ <crocket> braunr, Hurd is distributed, then.
+ <braunr> multiserver if you prefer
+ <braunr> yes it is
+ <crocket> braunr, So it is more difficult with hurd.
+ <crocket> How much more difficult? How do you debug?
+ <braunr> just keep in mind that a monolithic system can run on a
+ microkenrel
+ <braunr> we use tools that show us references
+ <crocket> braunr, like?
+ <braunr> like portinfo
+ <crocket> braunr, Does hurd use unix-socket to implement IPC?
+ <braunr> no
+ <braunr> unix-socket use mach ipc
+ <crocket> I'm confused
+ <braunr> ipc is provided by the microkernel, gnumach (a variant of mach)
+ <braunr> unix sockets are provided by one of the hurd servers (pflocal)
+ <braunr> servers and clients communicate through mach ipc
+ <crocket> braunr, Do you think it's feasible to build servers in haskell?
+ <braunr> why not ?
+ <crocket> ok
+ <teythoon> I've been thinking about that
+ <teythoon> in go, with cgo, you can call go functions from c code
+ <teythoon> so it should be possible to create bindings for say libtrivfs
+ <crocket> I'd like to write an OS in clojure or haskell.
+ <braunr> crocket: what for ?
+ <crocket> braunr, I want to see a better system programming language than
+ C.
+ <braunr> i don't see how clojure or haskell would be "better system
+ programming languages" than c
+ <braunr> and even assuming that, what for ?
+ <crocket> braunr, It's better for programmers.
+ <crocket> haskell
+ <crocket> haskell is expressive.
+ <braunr> personally i disagree
+ <braunr> it's better for some things
+ <braunr> not for system programming
+ <gnufreex> For system programming, Google Go is trying to replace C. But I
+ doubt it will.
+ <braunr> we may not be referring to the same thing here when we say "system
+ programming"
+ <crocket> braunr, What do you think is a better one?
+ <braunr> crocket: i don't think there is a better one currently
+ <crocket> braunr, Even Rust and D?
+ <braunr> i don't know them well enough
+ <braunr> certainly not D if it's what i think it is
+ <crocket> C is too slow.
+ <crocket> C is too slow to develop.
+ <braunr> depends
+ <braunr> again, i disagree
+ <braunr> rust looks good but i don't know it well to comment
+ <crocket> C is a tank, and clojure is an airplane.
+ <crocket> A tank is reliable but slow.
+ <crocket> Clojure is fast but lacks some accuracy.
+ <braunr> c is as reliable as the developer is skilled with it
+ <braunr> it's clearly not a tank
+ <braunr> there are many traps
+ <gnufreex> crocket: are you suggesting to rewrite Hurd in Clojure?
+ <crocket> no
+ <crocket> Why rewrite hud?
+ <crocket> hurd
+ <crocket> I'd rather start from scratch.
+ <braunr> which is what a rewrite is
+ <gnufreex> I am not expert on Clojure, but I don't think it is made for
+ system programming.
+ <gnufreex> If you want alternate language, I thing Go is only serious
+ candidate other than C
+ <crocket> Or Rust
+ <crocket> However, some people wrote OSes in haskell.
+ <braunr> again, why ?
+ <braunr> if it's only for the sake of using another language, i think it's
+ bad reason
+ <crocket> Because haskell provides a high level of abstraction that helps
+ programmers.
+ <crocket> It is more secure with monads.
+ <gnufreex> If you want your OS to become successful Free Software project,
+ you have to use popular language. Haskell is not.
+ <gnufreex> Most Haskell programmers are not into kernels
+ <gnufreex> They do high level stuff.
+ <gnufreex> So little contributors.
+ <braunr> crocket: so you aim at security ?
+ <gnufreex> I mean, candidats for contribution
+ <crocket> braunr, security and higher abstraction.
+ <braunr> i don't understand higher abstraction
+ <crocket> braunr, FP can be useful to systems.
+ <braunr> FP ?
+ <neal> functional programming
+ <braunr> right
+ <braunr> but you can abstract a lot with c too, with more efforts
+ <crocket> braunr, like that's easy.
+ <braunr> it's not that hard
+ <braunr> i'm just questioning the goals and the solution of using a
+ particular language
+ <braunr> the reason c is still the preferred language for system
+ programming is because it provides control over how the hardware does
+ stuff
+ <braunr> which is very important for performance
+ <braunr> the hurd never took off because of bad performance
+ <braunr> performance doesn't mean doing things faster, it means being able
+ to do things or not, or doing things a new way
+ <braunr> so ok, great, you have your amazing file system written in
+ haskell, and you find out it doesn't scale at all beyond some threshold
+ of processors or memory
+ <crocket> braunr, L4 is fast.
+ <braunr> l4 is merely an architecture abstraction
+ <braunr> and it's not written in haskell :p
+ <braunr> don't assume anything running on top of something fast will be
+ fast
+ <crocket> Hurd is slow and written in C.
+ <braunr> yes
+ <braunr> not because of c though
+ <crocket> Becuase it's microkernel?
+ <braunr> because c wasn't used well enough to make the most of the hardware
+ in many places
+ <braunr> far too many places
+ <crocket> A microkernel can be as fast as a monolithic kernel according to
+ L4.
+ <braunr> no
+ <braunr> it can't
+ <braunr> it can for very specific cases
+ <braunr> almost none of which are real world
+ <braunr> but that's not the problem
+ <braunr> again, i'm questioning your choice of another language in relation
+ to your goals, that's all
+ <braunr> c can do things you really can't do easily in other languages
+ <braunr> be aware of that
+ <crocket> braunr, "Monolithic kernel are faster than microkernel . while
+ The first microkernel Mach is 50% slower than Monolithic kernel while
+ later version like L4 only 2% or 4% slower than the Monolithic kernel ."
+ <braunr> 14:05 < braunr> but concerning microkernel stuff, you'll read a
+ lot of crap anywhere
+ <braunr> simple counterexample :
+ <braunr> the measurements you're giving consider a bare l4 kernel with
+ nothing on top of it
+ <braunr> doing thread-to-thread ipc
+ <braunr> this model of communication is hardly used in any real world
+ application
+ <braunr> one of the huge features people look for with microkernels are
+ capabilities
+ <braunr> and that alone will bump your 4% up
+ <braunr> since capabilities will be used for practically every ipc
+ <crocket> ok
+
+
+# Hurd From Scratch
+
+## IRC, freenode, #hurd, 2013-11-30
+
+ <hurdmaster> because I think there is no way to understand the whole pile,
+ you need to go step by step
+ <hurdmaster> for example, I'm starting with mach only, then adding one
+ server, then another and on each step I have working system
+ <hurdmaster> that's how I want to understand it
+ <teythoon> you are interested in the early bootstrapping of the hurd system
+ ?
+ <hurdmaster> now I'm starting debian gnu/mach, it hungs, show me black
+ screen and I have no idea how to fix it
+ <teythoon> if you are unable to fix this, why do you think you can build a
+ hurd system from scratch ?
+ <hurdmaster> not gnu/mach, gnu/hurd I mean
+ <teythoon> or, you could describe your problem in more detail and one of
+ the nice people around here might help you ;)
+ <hurdmaster> as I said, it will be easier to understand and fix bugs, if I
+ will go step by step, and I will be able to see where bugs appears
+ <hurdmaster> so you should help me with that
+ <teythoon> and I tend to disagree
+ <teythoon> but you could always read my blog. you'll learn lots of things
+ about bootstrapping a hurd system
+ <teythoon> but it's complicated
+ <hurdmaster> http://www.linuxfromscratch.org/
+ <teythoon> also, you'll need at least four hurd servers before you'll
+ actually see much
+ <teythoon> five
+ <teythoon> yeah, i know lfs
+ <hurdmaster> if somebody is interested in creating such a project, let me
+ know
+ <teythoon> you seem to be interested
+ <hurdmaster> yes, but I need the a real hurd master to help me
+ <teythoon> become one. fix your system and get to know it
+ <hurdmaster> I need knowledge, somebody built the system but didn't write
+ documentation about it, I have to extract it from your heads
+ <teythoon> hurdmaster: extract something from here
+ http://teythoon.cryptobitch.de
+ <teythoon> I need my head ;)
+ <hurdmaster> thanks
+ <hurdmaster> okay, what's the smallest thing I can run?
+ <teythoon> life of a Hurd system starts with the root filesystem, and the
+ exec server is loaded but not started
+ <teythoon> you could get rid of the exec server and replace the root
+ filesystem with your own program
+ <teythoon> statically linked, uses no unix stuff, only mach stuff
+ <hurdmaster> can I get 'hello world' on pure mach?
+ <teythoon> you could
+ <teythoon> hurdmaster: actually, here it is:
+ http://darnassus.sceen.net/gitweb/rbraun/mach_print.git/
+ <teythoon> compile it statically, put it somewhere in /boot
+ <teythoon> make sure you're running a debug kernel
+ <teythoon> load it from grub instead of /hurd/ext2fs.static
+ <teythoon> look at the grub config for how this is done
+ <teythoon> let me know if it worked ;)
+
+
+# IRC, freenode, #hurd, 2014-03-04
+
+ <bwright> Can I run a single instance of hurd on multiple computers
+ <bwright> With them acting as different servers?
+ <braunr> no
+ <bwright> Like the fs server on one pc etc.
+ <bwright> Which os could I do this with?
+ <bwright> I assumed Mach RPC would support that.
+ <braunr> it can
+ <braunr> but we don't use it that way
+ <braunr> plan9 is probably better suited to what you want
+ <braunr> inferno too
+ <braunr> maybe dragonflybsd
+ <bwright> Yep.
+ <bwright> irAwesome.
+ <bwright> Plan9 is exactly it.
+ <braunr> enjoy
+
+
+# IRC, freenode, #hurd, 2014-03-11
+
+ <ltx> Does anyone have a distributed OS over GNU/hurd project running?
+ <ltx> (GNU/hurd has many of the utilities to make this easy, but it still
+ requires some more utilities for transparent computation)
+ <braunr> not at the moment, no
+ <braunr> and i consider our ipc inappropriate if you want system able to
+ run over heterogeneous hardware
+ <braunr> or rather, our RPCs
+ <ltx> I haven't spent the time, this is speculative (in the worse "let's do
+ everything magically!" way.)
+ <ltx> Just wondering if this exists outside of plan9 (which is limited in
+ some ways.)
+ <braunr> dragonflybsd had plans for a SSI
+ <braunr> there are ancient research systems that actually did the job
+ <braunr> such as amoeba
+ <braunr> here at the hurd, we just don't have the manpower, and the people
+ spending time on the project have other interests
+ <ltx> Yeah, that seems like a large problem.
+ <ltx> GNU/hurd is self hosting (in the "I like working on it" way), yes?
+ <ltx> I've done some work on it, but don't really know how nice it is.
+ <braunr> yes it is
+ <ltx> Working from a microkernel to add pseudo-SSI features to a bunch of
+ servers seems like a much more trivial task than, say, modifying TLK.
+ <braunr> posix conformance and stability are good enough that more than 70%
+ of debian packages build and most of them work fine
+ <braunr> tlk the linux kernel ?
+ <ltx> Yes.
+ <braunr> first time i see this acronym :)
+ <braunr> and yes i agree, a microkernel is much much more suited for that
+ <braunr> but then, i consider a microkernel better suited for practically
+ everything ... :)
+ <ltx> :)
+ <ltx> I'm wondering how to mix SSI with network-awareness.
+ <braunr> mach used to have a network server
+ <braunr> which would merely act as a proxy for capabilities
+ <braunr> network drivers were in kernel though
+ <ltx> That's the simple way of sharing the sources.
+ <ltx> I'm wondering how we can make a software stack that's network aware;
+ completely transparent SSI can lead to inefficiencies in userspace, as it
+ may do things the kernels won't expect. Having to deal with the network
+ through a network server is a headache.
+ <braunr> what kind of problems do you have in mind ?
+ <ltx> Still working on defining the problem. I think that's half the
+ problem.
+ <ltx> (For any problem.)
+ <ltx> Beyond that, it's just some coding ;)
+ <braunr> ok
+ <braunr> sounds interesting :)
+ <braunr> i'd love to see a modern SSI in action
+ <braunr> but that's really a secondary goal for me so glad to see someone
+ making this his primary goal
+ <braunr> doctoral thesis ?
+ <ltx> ... Undergrad who's been hacking away since grade school.
+ <braunr> heh :)
+ <ltx> 18 y/o sophomore at a respected technical college, dealing with
+ boredom :)
+ <braunr> well throroughly thinking about "defining the problem" is an
+ excellent reflex
+ <teythoon> :) stick around, the hurd is fun
+ <braunr> it does help fight boredom a lot indeed ...... )
+ <braunr> :)
+ <cluck> maybe it'd be possible to port the relevant features from plan9 now
+ that there is a gpl'ed version
+ <teythoon> either way, we'd need network-transparent mach messaging
+ <teythoon> which mach messaging could do, but gnumach does not implement
+ this currently
+ <cluck> teythoon: afaiui if there was a proper 9fs2000 hurd server the rest
+ could be hidden behind the curtains
+ <teythoon> ah, well, that sounds like a 9p network filesystem translator
+ <cluck> teythoon: also iirc plan9 uses libmach for some things so i suppose
+ a port wouldn't be completely impossible
+ <teythoon> given that in plan9 everything is a file, that might be enough
+ to use plan9 services
+ <cluck> teythoon: yes, it'd be the easiest route (at least initially) i
+ believe
+ <teythoon> careful, lots of stuff is named mach-something
+ <cluck> bloody ernest mach and his damned famous-ness-ish
+ <cluck> =)
+ <teythoon> :D
diff --git a/open_issues/arm_port.mdwn b/open_issues/arm_port.mdwn
new file mode 100644
index 00000000..26e0b770
--- /dev/null
+++ b/open_issues/arm_port.mdwn
@@ -0,0 +1,267 @@
+[[!meta copyright="Copyright © 2012, 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]]."]]"""]]
+
+Several people have expressed interested in a port of GNU/Hurd for the ARM
+architecture.
+
+
+# IRC, freenode, #hurd, 2012-07-28
+
+ <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
+
+
+## IRC, freenode, #hurd, 2012-10-09
+
+ <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.
+
+
+## IRC, freenode, #hurd, 2012-10-10
+
+ <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...
+
+
+## IRC, freenode, #hurd, 2012-10-17
+
+ <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.
+
+
+# IRC, freenode, #hurd, 2012-11-15
+
+ <matty3269> Well, I have a big interest in the ARM architecture, I worked
+ at ARM for a bit too, and I've written my own little OS that runs on
+ qemu. Is there an interest in getting hurd running on ARM?
+ <braunr> matty3269: not really currently
+ <braunr> but if that's what you want to do, sure
+ <tschwinge> matty3269: Well, interest -- sure!, but we don't really have
+ people savvy in low-level kernel implementation on ARM. I do know some
+ bits about it, but more about the instruction set than about its memory
+ architecture, for example.
+ <tschwinge> matty3269: But if you're feeling adventurous, by all means work
+ on it, and we'll try to help as we can.
+ <tschwinge> matty3269: There has been one previous attempt for an ARM port,
+ but that person never published his code, and apparently moved to a
+ different project.
+ <tschwinge> matty3269: I can help with toolchains (GCC, etc.) things for
+ ARM, if there's need.
+ <matty3269> tschwinge: That sounds great, thanks! Where would you recommend
+ I start (at the moment I've got Mach checked out and am trying to get it
+ compiled for i386)
+ <matty3269> I'm guessing that the Mach micro-kernel is all that would need
+ to be ported or are there arch-dependant bits of code in the server
+ processes?
+ <tschwinge> matty3269:
+ http://www.gnu.org/software/hurd/faq/system_port.html has some
+ information. Mach is the biggest part, yes. Then some bits in glibc and
+ libpthread, and even less in the Hurd libraries and servers.
+ <tschwinge> matty3269: Basically, you'd need equivalents for the i386 (and
+ similar) directories, yep.
+ <tschwinge> Though, you may be able to avoid some cruft in there.
+ <tschwinge> Does building for x86 have any issues?
+ <tschwinge> matty3269: How is generally your understanding of the Hurd on
+ Mach system architecture, and on microkernel-based systems generally, and
+ on Mach in particular?
+ <matty3269> tschwinge: yes, it seems to be progressing... I've got mig
+ installed and it's just compiling now
+ <matty3269> hmm, not too great if I'm honest, I've done mostly monolithic
+ kernel development so having such low-level processes, such as
+ scheduling, done in user-space seems a little strinage
+ <tschwinge> Ah, yes, MIG will need a little bit of porting, too. I can
+ help with that, but that's not a priority -- first you have to get Mach
+ to boot at all; MIG will only be needed once you need to deal with RPCs,
+ so user-land/kernel interaction, basically. Before, you can hack around
+ it.
+ <matty3269> tschwinge: I have been running a GNU/Hurd system for a while
+ now though
+ <tschwinge> I'm happy to tell you that the schedules is still in the
+ kernel. ;-)
+ <tschwinge> OK, good, so you know about the basic ideas.
+ <braunr> matty3269: there has to be machine specific stuff in user space
+ <braunr> for initial thread contexts for example
+ <matty3269> tschwinge: Ok, just got gnumach built
+ <braunr> but there isn't much and you can easily base your work from the
+ x86 implementation
+ <tschwinge> Yes. Mach itself is the more difficult one.
+ <matty3269> braunr: Yeah, looking around at things, it doesn't seem that
+ there will be too much work involoved in the user-space stuff
+ <tschwinge> braunr: Do you know off-hand whether there are some old Mach
+ research papers describing architecture ports?
+ <tschwinge> I know there are some describing the memory system (obviously),
+ and I/O system -- which may help matty3269 to understand the general
+ design/structure.
+ <tschwinge> We might want to identify some documents, and make a list.
+ <braunr> all mach related documentation i have is available here:
+ ftp://ftp.sceen.net/mach/
+ <braunr> (also through http://)
+ <tschwinge> matty3269: Oh, definitely I'd suggest the Mach 3 Kernel
+ Principles book. That gives a good description of the Mach architecture.
+ <matty3269> Great, that's my weekends reading then!
+ <braunr> you don't need all that for a port
+ <matty3269> Is it possible to run the gnumach binary standalone with qemu?
+ <braunr> you won't go far with it
+ <braunr> you really need at least one program
+ <braunr> but sure, for a port development, it can easily be done
+ <braunr> i'd suggest writing a basic static application for your tests once
+ you reach an advanced state
+ <braunr> the critical parts of a port are memory and interrupts
+ <braunr> and memory can be particularly difficult to implement correctly
+ <tschwinge> matty3269: I once used QEMU's
+ virtual-FAT-filesystem-from-a-directory-on-the-host, and configured GRUB
+ to boot from that one, so it was easy to quickly reboot for kernel
+ development.
+ <braunr> but the good news is that almost every bsd system still uses a
+ similar interface
+ <tschwinge> matty3269: And, you may want to become familiar with QEMU's
+ built-in gdbserver, and how to connect to and use that.
+ <braunr> so, for example, you could base your work from the netbsd/arm pmap
+ module
+ <tschwinge> matty3269: I think that's better than starting on real
+ hardware.
+ <braunr> tschwinge: you can use -kernel with a multiboot binary now
+
+[[hurd/running/qemu#multiboot]].
+
+ <braunr> tschwinge: and even creating iso images is so fast it's not any
+ slower
+
+ <braunr> ah, the gnumach executable is a correct elf image
+ <matty3269> Is there particular reason that mach is linked at 0xc0100000?
+ <matty3269> or is that where it is expected to be in VM>
+ <tschwinge> That's my understanding.
+ <braunr> kernels commmonly sti at high addresses
+ <braunr> that's the "standard" 3G/1G split for user/kernel space
+ <matty3269> I think Linux sits at a similar VA for 32-bit
+ <braunr> no
+ <matty3269> Oh, I thought it did, I know it does on ARM, the kernel is
+ mapped to 0xc000000
+ <braunr> i don't know arm, but are you sure about this number ?
+ <braunr> seems to lack a 0
+ <matty3269> Ah, yes sorry
+ <matty3269> so 0xC0000000
+ <braunr> 0xc0100000 is just 1 MiB above it
+ <braunr> the .text section of linux on x86 actually starts at c1000000
+ (above 16 MiB, certainly to preserve as much dma-able memory since modern
+ machines now have a lot more)
+ <matty3269> so with gnumach, does the boot-up sequence use PIC until VM is
+ active and the kernel mapped to the linking address?
+ <braunr> no
+ <braunr> actually i'm not certain of the details
+ <braunr> but there is no PIC
+ <braunr> either special sections are linked at physical addresses
+ <braunr> or it relies on the fact that all executable code uses near jumps
+ <braunr> and uses offsets when accessing data
+ <braunr> (which is why the kernel text is at 3 GiB + 1 MiB, and not 3 GiB)
+ <matty3269> hmm,
+ <braunr> but you shouldn't worry about that i suppose, as the protocol
+ between the boot loader and an arm kernel will certainly not be the saem
+ <braunr> same*
+ <matty3269> indeed, ARM is tricky because memory maps are vastly differnt
+ on every platform
+
+
+## IRC, freenode, #hurd, 2012-11-21
+
+ <matty3269> Well, I have a ARM gnumach kernel compiled. It just doesn't
+ run! :)
+ <braunr> matty3269: good luck :)
+
+
+# IRC, freenode, #hurd, 2013-01-30
+
+ <slpz> Hi, i've read there's an ongoing effort to port GNU Mach to ARM. How
+ is it going?
+ <braunr> not sure where you read that
+ <braunr> but i'm pretty sure it's not started if it exists
+ <slpz> braunr: http://www.gnu.org/software/hurd/open_issues/arm_port.html
+ <braunr> i confirm what i said
+ <slpz> braunr: OK, thanks. I'm interested on it, and didn't want to
+ duplicate efforts.
+ <braunr> little addition: it may have started, but we don't know about it
+
+
+# IRC, freenode, #hurd, 2013-09-18
+
+ <Hooligan0> as i understand ; on startup, vm_resident.c functions configure
+ the whole available memory ; but at this point the system does not split
+ space for kernel and space for future apps
+ <Hooligan0> when pages are tagged to be used by userspace ?
+ <braunr> Hooligan0: at page fault time
+ <braunr> the split is completely virtual, vm_resident deals with physical
+ memory only
+ <Hooligan0> braunr: do you think it's possible to change (at least)
+ pmap_steal_memory to mark somes pages as kernel-reserved ?
+ <braunr> why do you want to reserve memory ?
+ <braunr> and which memory ?
+ <Hooligan0> braunr: first because on my mmu i have two entry points ; so i
+ want to set kernel pages into a dedicated space that never change on
+ context switch (for best cache performance)
+ <Hooligan0> braunr: and second, because i want to use larger pages into
+ kernel (1MB) to reduce mmu work
+ <braunr> vm_resident isn't well suited for large pages :(
+ <braunr> i don't see the effect of context switch on kernel pages
+ <Hooligan0> at many times, context switch flush caches
+ <braunr> ah you want something like global pages on x86 ?
+ <Hooligan0> yes, something like
+ <braunr> how is it done on arm ?
+ <Hooligan0> virtual memory is split into two parts depending on msb bits
+ <Hooligan0> for example 3G/1G
+ <Hooligan0> MMU will use two pages tables depending on vaddr (hi-side or
+ low-side)
+ <braunr> hi is kernel, low is user ?
+ <Hooligan0> so, for the moment i've put mach at 0xC0000000 -> 0xFFFFFFFF ;
+ and want to use 0x00000000 -> 0xBFFFFFFF for userspace
+ <Hooligan0> yes
+ <braunr> ok, that's what is done for x86 too
+ <Hooligan0> 1MB pages for kernel ; and 4kB (or 64kB) pages for apps
+ <braunr> i suggest you give up the large page stuff
+ <braunr> well, you can use them for the direct physical mapping, but for
+ kernel objects, it's a waste
+ <braunr> or you can rewrite vm_resident to use something like a buddy
+ allocator but it's additional work
+ <Hooligan0> for the moment it's waste ; but with some littles changes this
+ allow only one level of allocation mapping ; -i think- it's better for
+ performances
+ <braunr> Hooligan0: it is, but not worth it
+ <Hooligan0> will you allow changes into vm_resident if i update i386 too ?
+ <braunr> Hooligan0: sure, as long as these are relevant and don't introduce
+ regressions
+ <Hooligan0> ok
+ <braunr> Hooligan0: i suggest you look at x15, since you may want to use it
+ as a template for your own changes
+ <braunr> as it was done for the slab allocator for example
+ <braunr> e.g. x15 already uses a buddy allocator for physical memory
diff --git a/open_issues/automatic_backtraces_when_assertions_hit.mdwn b/open_issues/automatic_backtraces_when_assertions_hit.mdwn
new file mode 100644
index 00000000..df7294e9
--- /dev/null
+++ b/open_issues/automatic_backtraces_when_assertions_hit.mdwn
@@ -0,0 +1,79 @@
+[[!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/automatically_checking_port_deallocation.mdwn b/open_issues/automatically_checking_port_deallocation.mdwn
new file mode 100644
index 00000000..6aeaf207
--- /dev/null
+++ b/open_issues/automatically_checking_port_deallocation.mdwn
@@ -0,0 +1,32 @@
+[[!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]]
+
+IRC, unknown channel, unknown date.
+
+ <youpi> we really need something that is able to automatically check port deallocation
+ <youpi> at least for the trivial cases, for which we do have bugs I'm currently fixing...
+ <pochu> test suite? :)
+ <pochu> won't magically find them though, so not what you've asked for...
+ <youpi> test suites can trigger some of the bugs yes
+ <youpi> which is already a good thing
+ <youpi> of course the coverage can't be perfect
+ <youpi> one of the bugs I fixed happened only for setuid binaries for instance
+
+- - -
+
+portseal can automatically detect port leaks. It is somewhat
+intrusive, as it leverages a source-transformation and hence requires
+a recompilation of the code that contains the port leak. Currently,
+it is a prototype. If you are looking for a port leak, I'd love you
+to try it though:
+
+[[http://darnassus.sceen.net/gitweb/teythoon/portseal.git]]
diff --git a/open_issues/bash.mdwn b/open_issues/bash.mdwn
new file mode 100644
index 00000000..f6b14a08
--- /dev/null
+++ b/open_issues/bash.mdwn
@@ -0,0 +1,59 @@
+[[!meta copyright="Copyright © 2009, 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_porting]]
+
+
+# *bash* 4.0 vs. typing `C-c` (*SIGINT*)
+
+Will show `-bash: echo: write error: (ipc/mig) wrong reply message ID` unter
+certain conditions.
+
+After having noticed that this error doesn't occur if starting *bash* with
+`--norc`, I isolated it to the following command in `.bashrc`:
+
+ case $TERM in
+ xterm* | rxvt*)
+ PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME}:${PWD}\007"';;
+ esac
+
+... and indeed:
+
+ tschwinge@flubber:~ $ echo "$TERM" -- "$PROMPT_COMMAND"
+ xterm -- echo -ne "\033]0;${USER}@${HOSTNAME}:${PWD}\007"
+ tschwinge@flubber:~ $ ^C
+ -bash: echo: write error: (ipc/mig) wrong reply message ID
+ tschwinge@flubber:~ $ PROMPT_COMMAND=
+ tschwinge@flubber:~ $ ^C
+ tschwinge@flubber:~ $
+
+ bash-4.0$ PROMPT_COMMAND='echo >&2 -n foo\ '
+ foo bash-4.0$ ^C
+
+ bash-4.0$ PROMPT_COMMAND='echo >&1 -n foo\ '
+ foo bash-4.0$ ^C
+ bash: echo: write error: (ipc/mig) wrong reply message ID
+
+ bash-4.0$ PROMPT_COMMAND='/bin/echo >&1 -n foo\ '
+ foo bash-4.0$ ^C
+ 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/bash_busy-loop.mdwn b/open_issues/bash_busy-loop.mdwn
new file mode 100644
index 00000000..5228ba33
--- /dev/null
+++ b/open_issues/bash_busy-loop.mdwn
@@ -0,0 +1,33 @@
+[[!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]]."]]"""]]
+
+I've first seen this problem after having had the following command line run
+for a week, or two, or three:
+
+Start `screen`. Find PID of pfinet.
+
+ $ while sleep 66; do echo "$(date)" " $(ps --no-header --format=hurd -p [PID])"; done | tee ps-pfinet
+
+Leave it running, detach from `screen`.
+
+Eventually, the main `bash` process will go bonkers and eat 100 % CPU time.
+Reproduced on four different systems.
+
+A faster way to reproduce this, again inside `screen`; every three seconds,
+write text in 10 MiB bursts to the terminal:
+
+ $ while sleep 3; do date > tmp/tmp && yes "$(date)" | dd bs=1M count=10; done
+
+This one only needs like ten hours, before `bash` starts its busy-loop, from
+which it can only be terminated with `SIGKILL`. At this point, the `term`,
+`screen`, `fifo` processes also have used 40, 52, 25 minutes of CPU time,
+respectively, but appear to be still working fine.
+
+I did not yet start debugging this.
diff --git a/open_issues/bash_interrupted_system_call.mdwn b/open_issues/bash_interrupted_system_call.mdwn
new file mode 100644
index 00000000..9feab6ff
--- /dev/null
+++ b/open_issues/bash_interrupted_system_call.mdwn
@@ -0,0 +1,19 @@
+[[!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]]."]]"""]]
+
+IRC, unknown channel, unknown date.
+
+ <virtuoso015> i seem to be getting this message from the shell "-bash: /dev/fd/62: Interrupted system call"
+ <virtuoso015> is it significant ?
+ <youpi> I've seen this issue already yes
+ <youpi> it's not
+ <youpi> it's bash not handling EINTR properly
+ <antrik> youpi: so this is actually a bug in bash, not Hurd generating a bogus error?
+ <youpi> well, it's Hurd generating an error which bash doesn't expect to see
diff --git a/open_issues/bash_vs_screen_vs_sigint.mdwn b/open_issues/bash_vs_screen_vs_sigint.mdwn
new file mode 100644
index 00000000..9672041c
--- /dev/null
+++ b/open_issues/bash_vs_screen_vs_sigint.mdwn
@@ -0,0 +1,12 @@
+[[!meta copyright="Copyright © 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]]."]]"""]]
+
+ * [[bash]]
+ * [[screen]]
diff --git a/open_issues/benefits_of_a_native_hurd_implementation.mdwn b/open_issues/benefits_of_a_native_hurd_implementation.mdwn
new file mode 100644
index 00000000..dfd41837
--- /dev/null
+++ b/open_issues/benefits_of_a_native_hurd_implementation.mdwn
@@ -0,0 +1,139 @@
+[[!meta copyright="Copyright © 2010, 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_documentation]]
+
+What are the benefits of a native GNU/Hurd system, now that Linux et al. can do
+so much? Think [[hurd/translator]]s: FUSE, [[hurd/subhurd]]s: User-Mode-Linux
+and other virtualization techiques, and so on.
+
+It is possible to begin [[implementing_Hurd_on_top_of_another_system]], but...
+
+IRC, #hurd, August / September 2010
+
+ <marcusb> ArneBab: but Neal and I were not happy with that alone. We were
+ looking for deeper improvements to the system, for, I think, sound
+ reasons. That is what brought us to the L4/Coyotos technologies
+ <marcusb> ArneBab: as you are writing a kernel in user space, you can still
+ do kernel improvements there
+ <marcusb> ArneBab: if you take it very far, you end up with a kernel that
+ runs Linux in user space (just flip the two) for the drivers
+ <marcusb> ArneBab: that is what the L4 people did with the DDE
+
+[[/DDE]].
+
+ <marcusb> ArneBab: so, with these different cuts, there are different
+ opportunities. on the one end, you can run Linux as normal and get some
+ of the Hurd features such as translators in some programs. At the other
+ end, you can do whatever you want and run some linux code for the drivers
+ or none at all.
+ <marcusb> ArneBab: one of the big questions then becomes: at which point
+ can the advantages offered by the Hurd be realized?
+ <marcusb> ArneBab: and that's not entirely clear to me
+ <marcusb> when I worked on this with Neal, we pushed further and further
+ into need-to-change-everything land
+ <marcusb> while the current efforts on the Hurd seem to be more equivalent
+ to the could-run-it-in-userspace-on-top-of-Linux camp
+ <ArneBab> marcusb: for that I think we need a way to move towards them step
+ by step. Would it be possible to get the advantages of better resource
+ allocation with a Viengoos in userspace, too?
+ <ArneBab> and when that is stable, just switch over?
+ <marcusb> ArneBab: I don't know. I suspect these people will know before
+ us: http://lxc.sourceforge.net/
+ <ArneBab> something like implementing flip points: flip Linux with Hurd to
+ Hund with Linux. Flip Mach with L4 to L4 with Mach.
+ <ArneBab> lxc sounds interesting.
+ <marcusb> note that these efforts address security concerns more than other
+ concerns
+ <marcusb> so they will get isolation long before sharing is even considered
+ <marcusb> but some of the issues are the same
+ <marcusb> once you allow malware to do what it wants, it's a small step to
+ also allow the user to what he wants :)
+ <ArneBab> it kinda looks like hacking it where it doesn’t really fit again…
+ <ArneBab> there I ask myself when the point comes that doing a cleaner
+ design offsets the popularity
+ <ArneBab> they are pushing more and more stuff into userspace
+ <ArneBab> which is a good thing (to me)
+ <ArneBab> it’s hard to clearly describe how, but even though I like having
+ more stuff in userspace, the way it is bolted onto Linux doesn’t feel
+ good for me.
+ <ArneBab> FUSE is cool, but if I use it, I am at a disadvantage compared to
+ a non-fuse user
+ <ArneBab> while in the Hurd, these additional options are on eqal footing.
+ <marcusb> ArneBab: are they pushing more and more into user space? I don't
+ think so. I see more of the reverse, actually
+ <marcusb> or maybe both
+ <ArneBab> FUSE, lxd and scheduling in userspace move to userspace
+ <ArneBab> well, KMS moved to the kernel
+ <ArneBab> to avoid flickering when switching between X and the console?
+ <ArneBab> marcusb: Do you experience FUSE lxc and such being secondclass in
+ Linux, too, or is that just a strange feeling of me?
+ <ArneBab> marcusb: and that splits the users into those who can get stuff
+ into the kernel and those who can only work in userspace – which I don’t
+ really like.
+ <ArneBab> That’s one more advantage of the Hurd: eqal footing for all
+ (except the Mach hackers, but they have a very limited terrain)
+ <marcusb> ArneBab: but UML kernel module is minimal, and Linus didn't have
+ a principled objection to it (but just wanted a more general solution)
+ <marcusb> ArneBab: as a side note, although people keep complaining, the
+ linux kernel seems to be growing steadily, so getting stuff into the
+ kernel doesn't seem too hard. 8-O
+
+---
+
+IRC, #hurd, 2010-12-28
+
+ <tim> but is monolithic so bad?
+ <sartakov> yep
+ <braunr> no it's not
+ <braunr> proof: it works very well for most people
+ [...]
+ <braunr> the real problem is extensibility and interfaces
+ <tim> :/ whats the huge advantage of micro-k
+ <braunr> extensibility
+ <tim> over?
+ <braunr> you can add a whole lot of new services for new purposes with new
+ interfaces without changing the kernel
+ <tim> oright
+ <braunr> it basically boils down to the original Unix idea: everything does
+ one thing well
+ [...]
+ <kilobug> well, I would say extensibility and fault-tolerance are the two
+ key advantages
+ <braunr> taht's a side effect
+ <braunr> there are fault taulerant monolithic kernels
+ [...]
+ <braunr> tolerant*
+ <braunr> and the hurd is for now a non fault-tolerant microkernel based OS
+ :/
+ [...]
+ <kilobug> braunr: not really; you can't ensure fault tolerance for code
+ running in kernel space, code running in kernel space can do everything,
+ including reboot, crash, ...
+ [...]
+ <braunr> kilobug: right, a monolithick kernel is less folt-tolerant than a
+ well designed/implemented microkernel based os
+
+It turns out that it is perfectly possible to isolate services running in the
+same address space, as it was done in projects such as Singularity, the idea
+being that the code is verified through static analysis when installed (but
+this requires a language other than C).
+
+ <kilobug> braunr: well, the Hurd is buggy nowadays, but things like an
+ ext2fs translator doing a segfault and being restarted is a
+ fault-tolerance that would be almost impossible to have in Linux
+ <kilobug> braunr: sure, you can have fault-tolerance with FUSE, but FUSE is
+ applying micro-kernel paradigm to Linux
+ [...]
+ <braunr> the reason i don't care that much about fault tolerance is that
+ Linux obviously shows a monolithic kernel can run almost flawlessly if
+ well written
+ <braunr> but extensibility is really another matter
diff --git a/open_issues/binutils.mdwn b/open_issues/binutils.mdwn
new file mode 100644
index 00000000..306ba38a
--- /dev/null
+++ b/open_issues/binutils.mdwn
@@ -0,0 +1,954 @@
+[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2012, 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]]."]]"""]]
+
+[[!meta title=binutils-gdb]]
+
+[[!tag stable_URL open_issue_binutils open_issue_gdb]]
+
+Here's what's to be done for maintaining GNU Binutils and GDB.
+
+
+[[!toc levels=2]]
+
+
+# General Information
+
+
+## [[/Binutils]]
+
+As these tools primarily deal with low-level parts of the target architecture
+and the object file format (ELF ABI), which are essentially (at least meant to
+be) the same, there shouldn't be many differences comparing the binutils
+between the GNU/Hurd and GNU/Linux ports, for example. There are a few,
+though, as explained below.
+
+
+## [[/GDB]]
+
+GDB needs an processor architecture as well as operating system port.
+
+
+# Configuration
+
+<!--
+
+git checkout reviewed
+git diff --patience --stat=$COLUMNS,$COLUMNS --patch --src-prefix=./ --dst-prefix=./ --find-renames --ignore-space-change ..upstream/master | awk '/^diff/ { c = " " $0; } /^@@/ { print c; } { print; }' | less
+-i
+/^---.*/([^.]*|.*\.texi.*|[^/]*gnu[^/]*)$|hurd|linux|nacl|nptl|glibc|gs:
+
+-->
+
+Last reviewed up to Git commit c2853f3d99797a321c37948297441ca6021f719a
+(2014-02-14).
+
+ * Globally
+
+ * a.out (such as `ld/emulparams/i386linux.sh`, `ld/emultempl/linux.em`,
+ etc.), COFF, PE image support and 64-bit support are not interesting.
+
+ * In the testsuites, `.exp` and `.d` files very likely should not only
+ care for `*-*-linux*`, but also `*-*-gnu*`. (If they need to be
+ conditionalized like this at all.)
+
+ * `bfd/`
+
+ * `config.bfd`
+
+ * `i[3-7]86-*-gnu*`
+
+ Comparing to `i[3-7]86-*-linux-*`:
+
+ * `i386linux_vec` -- a.out.
+
+ * `i386pei_vec` -- PE.
+
+ * 64 bit.
+
+ * `configure.host`
+
+ Souldn't need anything. x86 Linux neither.
+
+ * `configure.in`
+
+ Linux:
+
+ * `COREFILE=trad-core.lo` with `TRAD_HEADER='"hosts/i386linux.h"'`
+
+ We don't have any such core file support configured. TODO: should
+ we? Where is this core file reading exactly used? GDB?
+
+ * `i386linux_vec` -- a.out.
+
+ * `i386pei_vec` -- PE.
+
+ * `binutils/`
+
+ * `configure.tgt`
+
+ * `gas/`
+
+ * `config/te-gnu.h`
+
+ C.f. `te-linux.h`; search tree for `TE_LINUX` vs. `TE_GNU` usage.
+
+ * `tc-i386.h`
+
+ Sole `TE_LINUX` usage is for a.out.
+
+ * `configure.tgt`
+
+ * `gdb/`
+
+ * Have a look at config/i386/i386gnu.mh.
+
+ * configure.tgt
+
+ * glibc-tdep et al. also for GNU/Hurd?
+
+ * [[gdb/gdbserver]]
+
+ * In `gdb/gnu-nat.c:gnu_wait`, we don't implement
+ `gdb/target/wait.h:TARGET_WNOHANG`. What is this needed for?
+
+ * `libdecnumber/`
+
+ Should/can probably align to GNU/Linux.
+
+ * `ld/`
+
+ * `configure.host`
+
+ * `*-*-gnu*`
+
+ TODO: resolve `crt0.o` vs. `crt1.o` issue. [[Testsuite
+ failures|binutils#static]].
+
+ * `configure.tgt`
+
+ * `i[3-7]86-*-gnu*`
+
+ Compare to `i[3-7]86-*-linux-*`, but don't need a.out (`i386linux`)
+ and 64 bit support.
+
+ * `__ehdr_start symbol`, c84ed8d89d0b8bf5a2968d465f77ac24bcfc40c2 -- can this
+ be helpful in the exec server, glibc, or elsewhere? Used in GDB (BFD)
+ commit bdbd9758806ed855af89244870fdc52cf3ff09bc.
+ Used in glibc commit 288f7d79fe2dcc8e62c539f57b25d7662a2cd5ff `Use
+ __ehdr_start, if available, as fallback for AT_PHDR.`.
+
+ * `Add HOSTING_SCRT0 for PIE test`, 49cc20aa5c416ea4307931cccf6353247368187d
+ -- is for GNU/Linux only; but also seems unused.
+
+ * 82763a3d329b0d342d0273941b1521be9ef0c604 »MODIFIED is unknown, pass it as
+ true.«
+
+ * Configure so that Debian system's `/usr/lib/debug/[...]` will be loaded
+ automatically.
+
+ * [[!message-id "m3ei24vh4l.fsf@fleche.redhat.com"]]
+
+ * [low] c26e9cbb0ce70e8fca32a40c434a0837bf46750a,
+ `gdb/gnu-nat.c:set_exceptions_cmd`, `Make this take effect immediately in a
+ running process`.
+
+ * [low] b27caf75c311991772b316fe7c0eecfd5788eeaf, ld, `Add HOSTING_SLIBS and
+ use it for -pie`. For us, too?
+
+
+# Build
+
+Here's a log of a binutils-gdb build run; this is from Git commit
+c2853f3d99797a321c37948297441ca6021f719a (2014-02-14) plus
+[[!message-id "87vbxxhww4.fsf@kepler.schwinge.homeip.net"]],
+[[!message-id "8738kyi30l.fsf@kepler.schwinge.homeip.net"]],
+[[!message-id "8761ofv62k.fsf@kepler.schwinge.homeip.net"]],
+[[!message-id "1391759958-972-2-git-send-email-yao@codesourcery.com"]],
+[[!message-id "1391759958-972-3-git-send-email-yao@codesourcery.com"]], run on
+kepler.SCHWINGE and coulomb.SCHWINGE.
+
+ $ export LC_ALL=C
+ $ ../W._C._Handy/configure --prefix="$PWD".install --enable-gold --with-sysroot=/ SHELL=/bin/dash CC=gcc-4.8 CXX=g++-4.8 --disable-werror 2>&1 | tee log_build
+ [...]
+ $ make 2>&1 | tee log_build_
+ [...]
+
+Different hosts may default to different shells and compiler versions; thus
+harmonized. Debian GCC (which is used in binutils' testsuite) likes to pass
+`--sysroot=/` to `ld`, so we need to configure binutils with support for
+sysroots. In the GDB build, there are several occurences of *error:
+dereferencing type-punned pointer will break strict-aliasing rules* in the
+MIG-generated stub files; thus no `-Werror` until that is resolved
+([[strict_aliasing]]).
+
+This takes up around 1.3 GiB, and needs roughly 17 min on kepler.SCHWINGE and
+79 min on coulomb.SCHWINGE.
+
+<!--
+
+ $ (make && touch .go-install) 2>&1 | tee log_build_ && test -f .go-install && (make install && touch .go-test) 2>&1 | tee log_install && test -f .go-test && make -k check 2>&1 | tee log_test
+
+-->
+
+
+## Analysis
+
+x86 GNU/Linux' and GNU/Hurd's configurations are slightly different, thus mask
+out most of the differences that are due to GNU/Linux supporting more core file
+formats, and more emulation vectors.
+
+ $ toolchain/logs/process binutils-gdb build
+
+ * For GDB, why do we specify `-D_GNU_SOURCE`, and GNU/Linux doesn't?
+
+ * GNU/Linux: `gdb/symfile-mem.c` for [[vDSO]].
+
+ * GNU/Linux: `gdb/i386-nat.c` for hardware breakpoints, etc. -- we should
+ probably use that, too. Related to Samuel's Hurd GDB patch?
+
+ * `gdb/gnu-nat.c`
+
+ gnu-nat.c: In function 'proc_set_exception_port':
+ gnu-nat.c:409:3: warning: format '%d' expects argument of type 'int', but argument 8 has type 'mach_port_t' [-Wformat]
+ gnu-nat.c: In function 'proc_steal_exc_port':
+ gnu-nat.c:449:7: warning: format '%d' expects argument of type 'int', but argument 8 has type 'mach_port_t' [-Wformat]
+ gnu-nat.c:470:7: warning: format '%d' expects argument of type 'int', but argument 8 has type 'mach_port_t' [-Wformat]
+ gnu-nat.c: In function 'make_proc':
+ gnu-nat.c:583:7: warning: format '%d' expects argument of type 'int', but argument 2 has type 'mach_port_t' [-Wformat]
+ gnu-nat.c:586:7: warning: format '%d' expects argument of type 'int', but argument 8 has type 'mach_port_t' [-Wformat]
+ gnu-nat.c: In function 'inf_set_pid':
+ gnu-nat.c:761:3: warning: format '%d' expects argument of type 'int', but argument 7 has type 'task_t' [-Wformat]
+ gnu-nat.c: In function 'inf_validate_procs':
+ gnu-nat.c:1085:6: warning: format '%d' expects argument of type 'int', but argument 8 has type 'thread_t' [-Wformat]
+ gnu-nat.c: In function 'inf_signal':
+ gnu-nat.c:1349:4: warning: format '%d' expects argument of type 'int', but argument 7 has type 'thread_t' [-Wformat]
+ gnu-nat.c:1349:4: warning: format '%d' expects argument of type 'int', but argument 8 has type 'thread_t' [-Wformat]
+ gnu-nat.c: In function 'S_exception_raise_request':
+ gnu-nat.c:1668:3: warning: format '%d' expects argument of type 'int', but argument 7 has type 'thread_t' [-Wformat]
+ gnu-nat.c:1668:3: warning: format '%d' expects argument of type 'int', but argument 8 has type 'task_t' [-Wformat]
+ gnu-nat.c:1705:8: warning: format '%d' expects argument of type 'int', but argument 7 has type 'mach_port_t' [-Wformat]
+ gnu-nat.c:1711:8: warning: format '%d' expects argument of type 'int', but argument 7 has type 'mach_port_t' [-Wformat]
+ gnu-nat.c: In function 'do_mach_notify_dead_name':
+ gnu-nat.c:1762:3: warning: format '%d' expects argument of type 'int', but argument 7 has type 'mach_port_t' [-Wformat]
+ gnu-nat.c: In function 'gnu_write_inferior':
+ gnu-nat.c:2383:8: warning: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'vm_address_t' [-Wformat]
+ gnu-nat.c:2393:8: warning: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'vm_address_t' [-Wformat]
+ gnu-nat.c: In function 'steal_exc_port':
+ gnu-nat.c:2864:5: warning: format '%d' expects argument of type 'int', but argument 2 has type 'mach_port_t' [-Wformat]
+
+ * fe19822761b4635f392875a186e48af446b40f41..7a63e9515491f21eaf07301df87d389def20e317:
+
+ `-Wmissing-prototypes`
+
+ notify_S.c:305:24: warning: no previous prototype for 'notify_server' []
+ notify_S.c:341:28: warning: no previous prototype for 'notify_server_routine' []
+ process_reply_S.c:343:24: warning: no previous prototype for 'process_reply_server' []
+ process_reply_S.c:379:28: warning: no previous prototype for 'process_reply_server_routine' []
+ msg_reply_S.c:165:24: warning: no previous prototype for 'msg_reply_server' []
+ msg_reply_S.c:201:28: warning: no previous prototype for 'msg_reply_server_routine' []
+ exc_request_S.c:157:24: warning: no previous prototype for 'exc_server' []
+ exc_request_S.c:193:28: warning: no previous prototype for 'exc_server_routine' []
+
+ * `O_NOFOLLOW`
+
+ First seen in
+ 20f498edfd7e57d3297febcf9c7c7d667cc74239..69a5e2b022c7d15ec4c7c49e6f53a8d924d3b72b:
+
+ -checking for working fcntl.h... yes
+ +checking for working fcntl.h... no (bad O_NOFOLLOW)
+
+ [[!taglink open_issue_glibc]]?
+
+
+# Install
+
+ $ make install 2>&1 | tee log_install
+ [...]
+
+This takes up around 200 MiB, and needs roughly 2 min on kepler.SCHWINGE and 6
+min on coulomb.SCHWINGE.
+
+
+## Analysis
+
+ $ toolchain/logs/process binutils-gdb install
+
+ * `libtool: finish`: `ldconfig` is not run for the Hurd.
+
+
+# Testsuite
+
+ $ make -k check 2>&1 | tee log_test
+ [...]
+
+This needs roughly 20 min on kepler.SCHWINGE and 140 min on coulomb.SCHWINGE.
+
+When running `make -k check 2>&1 | tee log_test`, at the end of the testsuite
+the `tee` process does not terminate if there are still stray leftover
+processes that [have their stdout/stderr
+open](http://sourceware.org/ml/gdb-patches/2012-10/msg00489.html). `kill`ing
+these (`SIGKILL` may be needed), makes the `tee` process terminate, too. On
+GNU/Hurd, these generally are `gdb.multi/watchpoint-multi`, and an unknown
+(`?`) GDB one ("57 PIDs before" `expect [...] gdb.cp`).
+
+
+## Analysis
+
+GDB's testsuite uses the system's default `gcc` (and similar) compilers, not
+those specified on the `configure` line ([[!taglink open_issue_gdb]]?), see
+`find_gcc` (and similar) usage in the testsuite and DejaGnu. Maybe something
+like `gdb/testsuite/boards/cc-with-tweaks.exp` would help, or setting
+`CC_FOR_TARGET` (and similar) per `gdb/testsuite/lib/future.exp`?
+
+ $ toolchain/logs/process binutils-gdb test
+
+ * <a name="static"><!-- stable_URL -->`FAIL: static [...]`</a>
+
+ The testsuite isn't prepared for using `crt0.o` instead of `crt1.o`
+ depending on whether a static or dynamic executable is created. Documented
+ in `ld/configure.host`. Perhaps we should finally rewrite this messy code
+ in glibc? Or, something similar to commit
+ 49cc20aa5c416ea4307931cccf6353247368187d `Add HOSTING_SCRT0 for PIE test`
+ or commit b27caf75c311991772b316fe7c0eecfd5788eeaf `Add HOSTING_SLIBS and
+ use it for -pie`
+ can be used.
+
+ Same issue for `FAIL: Common symbol override ifunc *` ones?
+
+ * <a name="64ksec">`FAIL: ld-elf/64ksec`</a>
+
+ On the idle grubber, this one takes a few minutes wall time to complete
+ successfully ([[I/O system
+ weakness|performance/io_system/binutils_ld_64ksec]]), so assuming some
+ system load variation, the testsuite's timeout may trigger.
+
+ * `FAIL: gas/i386/rept` (intermittently)
+
+ Added in commit 06f1247c54126b9f1e6acb8ff8c7be35aec6f44c (2012-06-07) as
+ part of the fix for [[!sourceware_PR 14201]], renamed in commit
+ d654e24bbc2f601df4dc43b26049b0339528b93a (2012-06-07):
+
+ WARNING: program timed out.
+ FAIL: gas/i386/rept
+
+ * ld IFUNC execution tests
+
+ Missing [[IFUNC]] support on GNU/Hurd.
+
+ Added in commit 82c5587db078581cfe94a4385ed99de1d1fa6657 (2012-09-19):
+
+ FAIL: Common symbol override ifunc test 1a
+ FAIL: Common symbol override ifunc test 1b
+
+ * gold GNU/Linux vs. GNU/Hurd
+
+ -FAIL: relro_test.sh
+ +PASS: relro_test.sh
+
+ -PASS: ver_matching_test.sh
+ +FAIL: ver_matching_test.sh
+
+ -PASS: script_test_3
+ +FAIL: script_test_3
+
+ -PASS: tls_phdrs_script_test
+ +FAIL: tls_phdrs_script_test
+
+ * `gdb.base/attach-pie-misread.exp`
+
+ Is only run for GNU/Linux; needs [[prelink]].
+
+ * Disabled
+
+ * `gdb.base/interrupt.exp`
+
+ PASS: gdb.base/interrupt.exp: child process is alive
+ a
+ a
+ PASS: gdb.base/interrupt.exp: child process ate our char
+ ^C
+ Program received signal SIGINT, Interrupt.
+ -0x010bf5a2 in _hurd_intr_rpc_mach_msg () from /lib/i386-gnu/libc.so.0.3
+ +0x010bdb09 in _hurd_intr_rpc_mach_msg () from /lib/i386-gnu/libc.so.0.3
+ (gdb) PASS: gdb.base/interrupt.exp: send_gdb control C
+ p func1 ()
+
+ Program received signal SIGTRAP, Trace/breakpoint trap.
+ -0x010bf5a2 in _hurd_intr_rpc_mach_msg () from /lib/i386-gnu/libc.so.0.3
+ +0x010bdb09 in _hurd_intr_rpc_mach_msg () from /lib/i386-gnu/libc.so.0.3
+ The program being debugged was signaled while in a function called from GDB.
+ GDB remains in the frame where the signal was received.
+ To change this behavior use "set unwindonsignal on".
+ Evaluation of the expression containing the function
+ (func1) will be abandoned.
+ When the function is done executing, GDB will silently stop.
+ (gdb) FAIL: gdb.base/interrupt.exp: call function when asleep (wrong output)
+ p func1 ()
+
+ Program received signal SIGTRAP, Trace/breakpoint trap.
+ -0x010bf5a2 in _hurd_intr_rpc_mach_msg () from /lib/i386-gnu/libc.so.0.3
+ +0x010bdb09 in _hurd_intr_rpc_mach_msg () from /lib/i386-gnu/libc.so.0.3
+ The program being debugged was signaled while in a function called from GDB.
+ GDB remains in the frame where the signal was received.
+ To change this behavior use "set unwindonsignal on".
+ Evaluation of the expression containing the function
+ (func1) will be abandoned.
+ When the function is done executing, GDB will silently stop.
+ (gdb) FAIL: gdb.base/interrupt.exp: call function a second time
+ continue
+ Continuing.
+ -PASS: gdb.base/interrupt.exp: continue
+ +
+ +Program received signal SIGSEGV, Segmentation fault.
+ +0x010bdb09 in _hurd_intr_rpc_mach_msg () from /lib/i386-gnu/libc.so.0.3
+ +(gdb) FAIL: gdb.base/interrupt.exp: continue
+ data
+ PASS: gdb.base/interrupt.exp: echo data
+ ^C(gdb) Quit
+ (gdb) FAIL: gdb.base/interrupt.exp: Send Control-C, second time
+ signal SIGINT
+ Continuing with signal SIGINT.
+ PASS: gdb.base/interrupt.exp: signal SIGINT
+ more data
+ PASS: gdb.base/interrupt.exp: echo more data
+
+ Program received signal SIGSEGV, Segmentation fault.
+ -0x010bf6c8 in _hurd_intr_rpc_mach_msg () from /lib/i386-gnu/libc.so.0.3
+ +0x010bdc9d in _hurd_intr_rpc_mach_msg () from /lib/i386-gnu/libc.so.0.3
+ (gdb) more data
+ Undefined command: "more". Try "help".
+ (gdb) FAIL: gdb.base/interrupt.exp: send end of file
+ -testcase ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/interrupt.exp completed in 6 seconds
+ +[hangs]
+
+ 7939 1000 6817 7939 7939 2 144M 8.92M 93.8 5:29.23 10hrs /media/erich/home/thomas/tmp/gdb/tschwinge/Ferry_Tagscherer.build/gdb/testsuite/../../gdb/gdb -nw -nx -data-directory /media/erich/home/thomas/tmp/gdb/tschwinge/Ferry_Tagscherer.build/gdb/testsuite/../data-directory
+ 7944 1000 7939 7944 7939 2 146M 744K 0.0 0:00.00 0:00.01 /media/erich/home/thomas/tmp/gdb/tschwinge/Ferry_Tagscherer.build/gdb/testsuite/gdb.base/interrupt
+
+ $ gdb -q tmp/gdb/tschwinge/Ferry_Tagscherer.build/gdb/gdb 7961
+ Reading symbols from /media/erich/home/thomas/tmp/gdb/tschwinge/Ferry_Tagscherer.build/gdb/gdb...done.
+ Attaching to program `/media/erich/home/thomas/tmp/gdb/tschwinge/Ferry_Tagscherer.build/gdb/gdb', pid 7961
+ [New Thread 7961.1]
+ [New Thread 7961.2]
+
+ warning: Can't modify tracing state for pid 7961: (ipc/rcv) timed out
+ Reading symbols [...]
+ (gdb) thread apply all bt full
+
+ Thread 2 (Thread 7961.2):
+ #0 0x014949cc in swtch_pri () at /build/eglibc-wYOBb2/eglibc-2.17/build-tree/hurd-i386-libc/mach/swtch_pri.S:2
+ No locals.
+ #1 0x01496354 in __spin_lock_solid (lock=0x168100c) at spin-solid.c:26
+ No locals.
+ #2 0x014aa677 in __spin_lock (__lock=<optimized out>) at ../mach/lock-intern.h:54
+ No locals.
+ #3 _hurd_sigstate_lock (ss=0x1681808) at hurdsig.c:175
+ No locals.
+ #4 0x014acbfb in post_signal (untraced=untraced@entry=0) at hurdsig.c:680
+ err = <optimized out>
+ handler = <optimized out>
+ blocked = <optimized out>
+ __PRETTY_FUNCTION__ = "post_signal"
+ signo = 11
+ act = 23593696
+ ss = 0x1681808
+ thread_state = {set = 0, basic = {gs = 1, fs = 17840912, es = 23594144, ds = 17840912, edi = 23290621, esi = 21506724, ebp = 23281960, esp = 1, ebx = 3, edx = 27255556, ecx = 23599112, eax = 163840, eip = 23273912,
+ cs = 29351492, efl = 29351424, uesp = 0, ss = 29351336}, fpu = {fpkind = 17840912, initialized = 29351344,
+ hw_state = "\364\213\002\000\000\000\000\000\000\000\000\000cfH\001\000\000\000\000\377\377\377\377\000 c\001T\244G\001\020;\020\001\b\030h\001\000\260g\001\370ݿ\001\060\357\277\001p\000\000\000\233\322e\001\220ݿ\001\216\246J\001\000\300b\001\260\341J\001\b\030h\001\000\000\000\000\000\000\000\000\000 c\001\022\000\000\000\000\200\002\000\020;\020\001\030\306b\001", exc_status = 359}}
+ ss_suspended = 0
+ reply = 0x1bfddf4
+ detail = 0x1bfde4c
+ #5 0x014ae29e in _hurd_internal_post_signal (ss=ss@entry=0x1681808, signo=11, detail=detail@entry=0x1bfde4c, reply_port=reply_port@entry=0, reply_port_type=reply_port_type@entry=17, untraced=untraced@entry=0) at hurdsig.c:1221
+ reply_rpc = 0x165d200 <__msg_sig_post_reply>
+ #6 0x014af98f in _S_catch_exception_raise (port=142, thread=112, task=1, exception=1, code=2, subcode=19137735) at catch-exc.c:88
+ ss = 0x1681808
+ signo = 11
+ d = {exc = 1, exc_code = 2, exc_subcode = 19137735, code = 2, error = EKERN_PROTECTION_FAILURE}
+ #7 0x016442c2 in _Xexception_raise (OutHeadP=0x1bfdf20, InHeadP=0x1bfef30) at /build/eglibc-wYOBb2/eglibc-2.17/build-tree/hurd-i386-libc/mach/mach/exc_server.c:150
+ No locals.
+ #8 _Xexception_raise (InHeadP=0x1bfef30, OutHeadP=0x1bfdf20) at /build/eglibc-wYOBb2/eglibc-2.17/build-tree/hurd-i386-libc/mach/mach/exc_server.c:41
+ In0P = 0x1bfef30
+ OutP = 0x1bfdf20
+ #9 0x01644344 in _S_exc_server (InHeadP=InHeadP@entry=0x1bfef30, OutHeadP=OutHeadP@entry=0x1bfdf20) at /build/eglibc-wYOBb2/eglibc-2.17/build-tree/hurd-i386-libc/mach/mach/exc_server.c:189
+ InP = 0x1bfef30
+ OutP = 0x1bfdf20
+ routine = 0x1644220 <_Xexception_raise>
+ #10 0x014a58ec in msgport_server (outp=0x1bfdf20, inp=0x1bfef30) at msgportdemux.c:49
+ No locals.
+ #11 msgport_server (inp=inp@entry=0x1bfef30, outp=outp@entry=0x1bfdf20) at msgportdemux.c:36
+ d = 0x0
+ #12 0x01495898 in __mach_msg_server_timeout (demux=demux@entry=0x14a5890 <msgport_server>, max_size=max_size@entry=4096, rcv_name=rcv_name@entry=142, option=option@entry=0, timeout=timeout@entry=0) at msgserver.c:108
+ request = 0x1bfef30
+ reply = 0x1bfdf20
+ mr = <optimized out>
+ __PRETTY_FUNCTION__ = "__mach_msg_server_timeout"
+ #13 0x014959cb in __mach_msg_server (demux=demux@entry=0x14a5890 <msgport_server>, max_size=4096, rcv_name=142) at msgserver.c:195
+ No locals.
+ #14 0x014a597d in _hurd_msgport_receive () at msgportdemux.c:67
+ No locals.
+ #15 0x010f7956 in entry_point (self=0x8520788, start_routine=0x14a5920 <_hurd_msgport_receive>, arg=0x0) at ./pthread/pt-create.c:61
+ No locals.
+ #16 0x00000000 in ?? ()
+ No symbol table info available.
+
+ Thread 1 (Thread 7961.1):
+ #0 _hurd_userlink_unlink (link=0x81c2a20 <command_handler+48>) at ../hurd/hurd/userlink.h:123
+ No locals.
+ #1 __sigreturn (scp=0x81c2950 <handle_sigint>) at ../sysdeps/mach/hurd/i386/sigreturn.c:47
+ link = 0x81c2a20 <command_handler+48>
+ reply_port = <optimized out>
+ #2 0x014aef46 in trampoline () from /lib/i386-gnu/libc.so.0.3
+ No locals.
+ #3 0x081c2950 in ?? () at ../../Ferry_Tagscherer/gdb/event-top.c:869
+ sigtstp_token = 0x860a7c0
+ sighup_token = 0x86089e0
+ more_to_come = 0
+ sigfpe_token = 0x860a7a8
+ sigquit_token = 0x86089c8
+ sigint_token = 0x860a3b0
+ call_readline = 0x81c2ab0 <rl_callback_read_char_wrapper>
+ exec_done_display_p = 0
+ input_handler = 0x81c2c50 <command_line_handler>
+ async_command_editing_p = 1
+ after_char_processing_hook = 0x0
+ async_annotation_suffix = 0x83d8648 "prompt"
+ input_fd = 0
+ readline_input_state = {linebuffer = 0x0, linebuffer_ptr = 0x0}
+ Backtrace stopped: previous frame inner to this frame (corrupt stack?)
+ (gdb) kill
+ Kill the program being debugged? (y or n) y
+
+ * `gdb.base/readline.exp`
+
+ [[term_blocking]] issue.
+
+ * `gdb.base/sigall.exp`
+
+ From `send signal TSTP` on, all FAIL running into timeouts.
+
+ * `gdb.python/py-inferior.exp` (mostly disabled)
+
+ Running ../../../Ferry_Tagscherer/gdb/testsuite/gdb.python/py-inferior.exp ...
+ [...]
+ python print 'result =', i0.was_attached
+ result = False
+ (gdb) PASS: gdb.python/py-inferior.exp: test Inferior.was_attached
+ python print i0.threads ()
+ (<gdb.InferiorThread object at 0x61170>, <gdb.InferiorThread object at 0x61160>)
+ (gdb) FAIL: gdb.python/py-inferior.exp: test Inferior.threads
+ break check_threads
+ Breakpoint 2 at 0x8048869: file ../../../Ferry_Tagscherer/gdb/testsuite/gdb.python/py-inferior.c, line 61.
+ (gdb) continue
+ Continuing.
+ [New Thread 25670.6]
+ [New Thread 25670.7]
+ [New Thread 25670.8]
+ [New Thread 25670.9]
+ [New Thread 25670.10]
+ [New Thread 25670.11]
+ [New Thread 25670.12]
+ [New Thread 25670.13]
+
+ Breakpoint 2, check_threads (barrier=0x15ff144) at ../../../Ferry_Tagscherer/gdb/testsuite/gdb.python/py-inferior.c:61
+ 61 pthread_barrier_wait (barrier);
+ (gdb) PASS: gdb.python/py-inferior.exp: continue to breakpoint: cont to check_threads
+ python print len (i0.threads ())
+ 10
+ (gdb) FAIL: gdb.python/py-inferior.exp: test Inferior.threads 2
+ break 28
+ Breakpoint 3 at 0x80487c2: file ../../../Ferry_Tagscherer/gdb/testsuite/gdb.python/py-inferior.c, line 28.
+ (gdb) continue
+ Continuing.
+ FAIL: gdb.python/py-inferior.exp: continue to breakpoint: cont to Break here. (timeout)
+ python addr = gdb.selected_frame ().read_var ('str')
+ FAIL: gdb.python/py-inferior.exp: read str address (timeout)
+ [All following tests FAIL with timeout.]
+ FAIL: gdb.python/py-inferior.exp: Switch to first inferior (timeout)
+ remove-inferiors 3
+ FAIL: gdb.python/py-inferior.exp: Remove second inferior (timeout)
+
+ At this point, the system hangs; no new processes can be spawned, so
+ perhaps an issue with the exec server.
+
+ * `gdb.threads/manythreads.exp`
+
+ [[!taglink open_issue_libpthread]]. Perhaps fails due to pthread
+ attributes usage? Doesn't execute properly:
+
+ $ gdb/testsuite/gdb.threads/manythreads
+ manythreads: ../libpthread/sysdeps/mach/pt-thread-halt.c:51: __pthread_thread_halt: Unexpected error: (ipc/rcv) invalid name.
+ Killed
+
+ * Linux syscall usage, `<asm/unistd.h>`
+
+ * `UNSUPPORTED: gdb.threads/ia64-sigill.exp: Couldn't compile ../../../master/gdb/testsuite/gdb.threads/ia64-sigill.c: unrecognized error`
+
+ * `UNSUPPORTED: gdb.threads/siginfo-threads.exp: Couldn't compile ../../../Ferry_Tagscherer/gdb/testsuite/gdb.threads/siginfo-threads.c: unrecognized error`
+
+ * `gdb.threads/sigstep-threads.c`
+
+ Also uses `tgkill`.
+
+ * `UNSUPPORTED: gdb.threads/watchpoint-fork.exp: parent: multithreaded: Couldn't compile ../../../Ferry_Tagscherer/gdb/testsuite/gdb.threads/watchpoint-fork-mt.c ../../../Ferry_Tagscherer/gdb/testsuite/gdb.threads/watchpoint-fork-parent.c: unrecognized error`
+
+ * `UNSUPPORTED: gdb.threads/multi-create.exp: Couldn't compile ../../../master/gdb/testsuite/gdb.threads/multi-create.c: unrecognized error`
+ ../../../master/gdb/testsuite/gdb.threads/multi-create.c: In function 'create_function':
+ ../../../master/gdb/testsuite/gdb.threads/multi-create.c:46:39: error: 'PTHREAD_STACK_MIN' undeclared (first use in this function)
+ ../../../master/gdb/testsuite/gdb.threads/multi-create.c:46:39: note: each undeclared identifier is reported only once for each function it appears in
+ ../../../master/gdb/testsuite/gdb.threads/multi-create.c: In function 'main':
+ ../../../master/gdb/testsuite/gdb.threads/multi-create.c:73:39: error: 'PTHREAD_STACK_MIN' undeclared (first use in this function)
+
+ * `UNSUPPORTED: gdb.threads/staticthreads.exp: Couldn't compile ../../../master/gdb/testsuite/gdb.threads/staticthreads.c: unrecognized error`
+
+ ../../../master/gdb/testsuite/gdb.threads/staticthreads.c: In function 'main':
+ ../../../master/gdb/testsuite/gdb.threads/staticthreads.c:52:37: error: 'PTHREAD_STACK_MIN' undeclared (first use in this function)
+ ../../../master/gdb/testsuite/gdb.threads/staticthreads.c:52:37: note: each undeclared identifier is reported only once for each function it appears in
+
+ * `UNSUPPORTED: gdb.threads/create-fail.exp: Couldn't compile ../../../Ferry_Tagscherer/gdb/testsuite/gdb.threads/create-fail.c: unrecognized error`
+
+ [...]/gdb.threads/create-fail.c:77: undefined reference to `pthread_attr_setaffinity_np'
+ [...]/gdb.threads/create-fail.c:83: undefined reference to `pthread_create'
+
+ * `UNTESTED: gdb.base/longest-types.exp: longest-types.exp`
+
+ ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/longest-types.c:20:8: error: size of array 'buf' is too large
+
+ Also on GNU/Linux.
+
+ * `FAIL: gdb.base/jit.exp: PIE: one_jit_test-1: Can't run to main`
+
+ (gdb) break main
+ Breakpoint 1 at 0xb84: file ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/jit-main.c, line 128.
+ (gdb) run
+ Starting program: /media/erich/home/thomas/tmp/gdb/tschwinge/Ferry_Tagscherer.build/gdb/testsuite/gdb.base/jit-main
+ Cannot access memory at address 0x393
+ Cannot access memory at address 0x38f
+ (gdb) FAIL: gdb.base/jit.exp: PIE: one_jit_test-1: Can't run to main
+
+ [[GCC/PIE]].
+
+ Is the following supposed to terminate in this way?
+
+ (gdb) break main
+ Breakpoint 1 at 0x675: file ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/attach-pie-noexec.c, line 23.
+ (gdb) run
+ Starting program: /media/erich/home/thomas/tmp/gdb/tschwinge/Ferry_Tagscherer.build/gdb/testsuite/gdb.base/attach-pie-noexec
+ Cannot access memory at address 0x6c626172
+ Cannot access memory at address 0x6c62616e
+ (gdb) testcase ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/attach-pie-noexec.exp completed in 3 seconds
+
+ IRC, freenode, #hurd, 2013-09-06:
+
+ <gnu_srs1> How to debug a program that works in the shell but Cannot
+ access memory at address ... in gdb?
+ <tschwinge> Build it without -pie -- but that is just a guess of what
+ might be going on.
+ * tschwinge clearly has spent enough time with obscure things to be
+ able to make such guesses.
+ <gnu_srs1> tschwinge: looks like -fPIE is used.
+ <gnu_srs1> verified: some (all?) executables compiled with -fPIE, -fpie
+ and linked with -pie cannot be debugged in gdb :(
+
+ * `solib-event stop`
+
+ Running ../../../Ferry_Tagscherer/gdb/testsuite/gdb.mi/mi-catch-load.exp ...
+ PASS: gdb.mi/mi-catch-load.exp: breakpoint at main
+ PASS: gdb.mi/mi-catch-load.exp: mi runto main
+ PASS: gdb.mi/mi-catch-load.exp: catch-load: auto-solib-add on
+ PASS: gdb.mi/mi-catch-load.exp: catch-load: catch load
+ FAIL: gdb.mi/mi-catch-load.exp: catch-load: solib-event stop
+ PASS: gdb.mi/mi-catch-load.exp: breakpoint at main
+ PASS: gdb.mi/mi-catch-load.exp: mi runto main
+ PASS: gdb.mi/mi-catch-load.exp: catch-unload: auto-solib-add on
+ PASS: gdb.mi/mi-catch-load.exp: catch-unload: catch unload
+ FAIL: gdb.mi/mi-catch-load.exp: catch-unload: solib-event stop
+
+ *stopped,reason="signal-received",signal-name="SIGSEGV",signal-meaning="Segmentation fault",frame={addr="0x00014add",func="??",args=[],from="/lib/ld.so"},thread-id="4",stopped-threads="all"
+
+ * `gdb.base/call-signal-resume.exp`
+
+ $ gdb -q gdb/testsuite/gdb.base/call-signals
+ (gdb) break stop_one
+ (gdb) r
+ (gdb) call gen_signal()
+ (gdb) bt
+ (gdb) frame [<function called from gdb>]
+ (gdb) return
+ (gdb) break handle_signal
+ (gdb) c
+ (gdb) c
+
+ kepler.SCHWINGE:
+
+ Breakpoint 2, handle_signal (sig=6) at ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/call-signals.c:28
+ 28 }
+ (gdb) bt
+ #0 handle_signal (sig=6) at ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/call-signals.c:28
+ #1 <signal handler called>
+ #2 0xb7fde416 in __kernel_vsyscall ()
+ #3 0xb7dffd96 in kill () at ../sysdeps/unix/syscall-template.S:81
+ #4 0x0804859c in gen_signal () at ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/call-signals.c:35
+ #5 0x08048610 in main () at ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/call-signals.c:81
+
+ coulomb.SCHWINGE:
+
+ Breakpoint 2, handle_signal (sig=6) at ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/call-signals.c:28
+ 28 }
+ (gdb) bt
+ #0 handle_signal (sig=6) at ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/call-signals.c:28
+ #1 0x010baac2 in trampoline () from /lib/i386-gnu/libc.so.0.3
+ #2 0x00000006 in ?? ()
+ #3 0x00000000 in ?? ()
+
+ kepler.SCHWINGE:
+
+ (gdb) c
+ Continuing.
+ no signal
+ [Inferior 1 (process 10401) exited normally]
+
+ coulomb.SCHWINGE:
+
+ (gdb) c
+ Continuing.
+ no signal
+
+ Program received signal SIGSEGV, Segmentation fault.
+ 0x00000000 in ?? ()
+ (gdb) bt
+ #0 0x00000000 in ?? ()
+ #1 0x01116c28 in _IO_acquire_lock_fct (p=<synthetic pointer>) at libioP.h:905
+ #2 _IO_puts (str=0x80487e0 "no signal") at ioputs.c:45
+ #3 0x080486d8 in gen_signal () at ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/call-signals.c:38
+ #4 0x0804873d in main () at ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/call-signals.c:81
+
+ This is apparently new with the glibc 2.17 upgrade. If not doing the
+ manual `gen_signal` call, it works fine. TODO.
+
+ * `gdb.base/relativedebug.exp`
+
+ (gdb) PASS: gdb.base/relativedebug.exp: continue
+ bt
+ #0 0x010a1afc in ?? () from /lib/i386-gnu/libc.so.0.3
+ #1 0x010a23be in mach_msg () from /lib/i386-gnu/libc.so.0.3
+ #2 0x0126cd98 in msg_sig_post () from /lib/i386-gnu/libhurduser.so.0.3
+ #3 0x010e2141 in ?? () from /lib/i386-gnu/libc.so.0.3
+ #4 0x010e23ed in kill () from /lib/i386-gnu/libc.so.0.3
+ #5 0x010e17f4 in raise () from /lib/i386-gnu/libc.so.0.3
+ #6 0x010e5b7c in abort () from /lib/i386-gnu/libc.so.0.3
+ #7 0x08048607 in handler (signo=14) at ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/relativedebug.c:25
+ #8 0x010bdac2 in ?? () from /lib/i386-gnu/libc.so.0.3
+ Backtrace stopped: previous frame inner to this frame (corrupt stack?)
+ (gdb) FAIL: gdb.base/relativedebug.exp: pause found in backtrace
+
+ This is apparently new with the glibc 2.17 upgrade. Previously it said:
+
+ (gdb) PASS: gdb.base/relativedebug.exp: continue
+ bt
+ #0 0x0107c85c in ?? () from /lib/i386-gnu/libc.so.0.3
+ #1 0x0107d069 in mach_msg () from /lib/i386-gnu/libc.so.0.3
+ #2 0x01220d4f in msg_sig_post () from /lib/i386-gnu/libhurduser.so.0.3
+ #3 0x010bb683 in ?? () from /lib/i386-gnu/libc.so.0.3
+ #4 0x010bb8f6 in kill () from /lib/i386-gnu/libc.so.0.3
+ #5 0x010bad76 in raise () from /lib/i386-gnu/libc.so.0.3
+ #6 0x010bf029 in abort () from /lib/i386-gnu/libc.so.0.3
+ #7 0x08048597 in handler (signo=14) at ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/relativedebug.c:25
+ #8 0x01098282 in ?? () from /lib/i386-gnu/libc.so.0.3
+ #9 0x010bbe5a in sigsuspend () from /lib/i386-gnu/libc.so.0.3
+ #10 0x0112fee1 in pause () from /lib/i386-gnu/libc.so.0.3
+ #11 0x080485c5 in main () at ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/relativedebug.c:32
+ (gdb) PASS: gdb.base/relativedebug.exp: pause found in backtrace
+
+ TODO.
+
+ * `gdb.gdb/selftest.exp`
+
+ (gdb) PASS: gdb.gdb/selftest.exp: send SIGINT signal to child process
+ backtrace
+ #0 0x0146fafc in ?? () from /lib/i386-gnu/libc.so.0.3
+ #1 0x014703be in mach_msg () from /lib/i386-gnu/libc.so.0.3
+ #2 0x0163bd98 in msg_sig_post () from /lib/i386-gnu/libhurduser.so.0.3
+ #3 0x014b0141 in ?? () from /lib/i386-gnu/libc.so.0.3
+ #4 0x014b03ed in kill () from /lib/i386-gnu/libc.so.0.3
+ #5 0x082cf471 in _rl_handle_signal (sig=2) at ../../Ferry_Tagscherer/readline/signals.c:221
+ #6 0x0148bac2 in ?? () from /lib/i386-gnu/libc.so.0.3
+ Backtrace stopped: previous frame inner to this frame (corrupt stack?)
+ (gdb) FAIL: gdb.gdb/selftest.exp: backtrace through signal handler
+
+ This is apparently new with the glibc 2.17 upgrade. Previously it said:
+
+ (gdb) PASS: gdb.gdb/selftest.exp: send SIGINT signal to child process
+ backtrace
+ #0 0x0144885c in ?? () from /lib/i386-gnu/libc.so.0.3
+ #1 0x01449069 in mach_msg () from /lib/i386-gnu/libc.so.0.3
+ #2 0x015ecd4f in msg_sig_post () from /lib/i386-gnu/libhurduser.so.0.3
+ #3 0x01487683 in ?? () from /lib/i386-gnu/libc.so.0.3
+ #4 0x014878f6 in kill () from /lib/i386-gnu/libc.so.0.3
+ #5 0x082cf401 in _rl_handle_signal (sig=2) at ../../Ferry_Tagscherer/readline/signals.c:221
+ #6 0x01464282 in ?? () from /lib/i386-gnu/libc.so.0.3
+ #7 0x0144fce3 in ?? () from /lib/i386-gnu/libc.so.0.3
+ #8 0x0153975b in poll () from /lib/i386-gnu/libc.so.0.3
+ #9 0x081c91c2 in gdb_wait_for_event (block=1) at ../../Ferry_Tagscherer/gdb/event-loop.c:804
+ #10 0x081c998f in gdb_do_one_event () at ../../Ferry_Tagscherer/gdb/event-loop.c:402
+ #11 0x081c9b07 in start_event_loop () at ../../Ferry_Tagscherer/gdb/event-loop.c:431
+ #12 0x081c2f42 in captured_command_loop (data=data@entry=0x0) at ../../Ferry_Tagscherer/gdb/main.c:260
+ #13 0x081c0e57 in catch_errors (func=func@entry=0x81c2f30 <captured_command_loop>, func_args=func_args@entry=0x0, errstring=errstring@entry=0x83
+ 5b81b "", mask=mask@entry=6) at ../../Ferry_Tagscherer/gdb/exceptions.c:546
+ #14 0x081c388c in captured_main (data=data@entry=0x19ff150) at ../../Ferry_Tagscherer/gdb/main.c:1055
+ #15 0x081c0e57 in catch_errors (func=func@entry=0x81c3130 <captured_main>, func_args=func_args@entry=0x19ff150, errstring=errstring@entry=0x835b
+ 81b "", mask=mask@entry=6) at ../../Ferry_Tagscherer/gdb/exceptions.c:546
+ #16 0x081c43c0 in gdb_main (args=0x19ff150) at ../../Ferry_Tagscherer/gdb/main.c:1064
+ #17 0x08099533 in main (argc=5, argv=0x19ff1e8) at ../../Ferry_Tagscherer/gdb/gdb.c:34
+ (gdb) PASS: gdb.gdb/selftest.exp: backtrace through signal handler
+
+ TODO.
+
+ * `gdb.base/restore.exp`, `gdb.base/store.exp`
+
+ Several FAILs, starting with GCC 4.8 usage:
+
+ (gdb) PASS: gdb.base/restore.exp: caller3 calls callee1; return callee now
+ print l1
+ $16 = <optimized out>
+ (gdb) FAIL: gdb.base/restore.exp: caller3 calls callee1; return restored l1 to 32492
+
+ [[!GCC_PR 55056]], [[!message-id
+ "20130126202645.GA4888@host2.jankratochvil.net"]], and maybe [[!message-id
+ "CAO2gOZXvCLdaKE2=ZKpjGVGq8A0wQ94-AUo7eKvvWHWncrU_yg@mail.gmail.com"]] look
+ related.
+
+ * `gdb.base/default.exp`
+
+ shell echo Hi dad!
+ bash: relocation error: /lib/i386-gnu/libdl.so.2: symbol __libc_lock_self, version GLIBC_PRIVATE not defined in file libc.so.0.3 with link time reference
+ (gdb) FAIL: gdb.base/default.exp: shell echo Hi dad!
+
+ TODO.
+
+ * `gdb.base/exitsignal.exp`
+
+ Running ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/exitsignal.exp ...
+ PASS: gdb.base/exitsignal.exp: $_exitsignal is void before running
+ PASS: gdb.base/exitsignal.exp: $_exitcode is void before running
+ PASS: gdb.base/exitsignal.exp: trigger SIGSEGV
+ PASS: gdb.base/exitsignal.exp: program terminated with SIGSEGV
+ FAIL: gdb.base/exitsignal.exp: $_exitsignal is 11 (SIGSEGV) after SIGSEGV.
+ PASS: gdb.base/exitsignal.exp: $_exitcode is still void after SIGSEGV
+ PASS: gdb.base/exitsignal.exp: rerun to main
+ FAIL: gdb.base/exitsignal.exp: $_exitsignal is 11 (SIGSEGV) after restarting the inferior
+ PASS: gdb.base/exitsignal.exp: $_exitcode is still void after restarting the inferior
+ PASS: gdb.base/exitsignal.exp: $_exitsignal is void before normal inferior is executed
+ PASS: gdb.base/exitsignal.exp: $_exitcode is void before normal inferior is executed
+ PASS: gdb.base/exitsignal.exp: continue until exit
+ PASS: gdb.base/exitsignal.exp: $_exitcode is zero after normal inferior is executed
+ PASS: gdb.base/exitsignal.exp: $_exitsignal is still void after normal inferior is executed
+
+ TODO.
+
+ * `gdb.arch/i386-prologue.exp`
+
+ There are several FAILs, where there are unexpected frames showing up in
+ backtraces, for example. Earlier on, these just FAILed on
+ coulomb.SCHWINGE; since
+ 9939e1314f970c6ba568956148a518ac710a280a..c2853f3d99797a321c37948297441ca6021f719a
+ on kepler.SCHWINGE, too. TODO.
+
+ * [[libgc|boehm_gc]] `GC_find_limit_with_bound` SIGSEGVs
+
+ On coulomb.SCHWINGE, in
+ 9939e1314f970c6ba568956148a518ac710a280a..c2853f3d99797a321c37948297441ca6021f719a
+ several PASSes regressed to FAILs:
+
+ Starting program: [...]/gdb/testsuite/gdb.gdb/xgdb -nw -nx -data-directory [...]/gdb/testsuite/../data-directory
+ [New Thread 13417.5]
+
+ Program received signal SIGSEGV, Segmentation fault.
+ 0x0126b961 in GC_find_limit_with_bound () from /usr/lib/i386-gnu/libgc.so.1
+ (gdb) FAIL: gdb.gdb/complaints.exp: run until breakpoint at captured_command_loop
+ WARNING: Couldn't test self
+
+ Starting program: [...]/gdb/testsuite/gdb.gdb/xgdb -nw -nx -data-directory [...]/gdb/testsuite/../data-directory
+ [New Thread 13448.5]
+
+ Program received signal SIGSEGV, Segmentation fault.
+ 0x0126b961 in GC_find_limit_with_bound () from /usr/lib/i386-gnu/libgc.so.1
+ (gdb) FAIL: gdb.gdb/python-interrupts.exp: run until breakpoint at captured_command_loop
+ WARNING: Couldn't test self
+
+ Starting program: [...]/gdb/testsuite/gdb.gdb/xgdb -nw -nx -data-directory [...]/gdb/testsuite/../data-directory
+ [New Thread 13464.3]
+
+ Program received signal SIGSEGV, Segmentation fault.
+ 0x0126b961 in GC_find_limit_with_bound () from /usr/lib/i386-gnu/libgc.so.1
+ (gdb) FAIL: gdb.gdb/python-selftest.exp: run until breakpoint at captured_command_loop
+ WARNING: Couldn't test self
+
+ (gdb) PASS: gdb.gdb/selftest.exp: step into xmalloc call
+ continue
+ Continuing.
+
+ Program received signal SIGSEGV, Segmentation fault.
+ 0x0126b961 in GC_find_limit_with_bound () from /usr/lib/i386-gnu/libgc.so.1
+ (gdb) FAIL: gdb.gdb/selftest.exp: xgdb is at prompt
+
+ These are all tests where GDB examines itself; being linked against libgc
+ (new dependency due to new Guile scripting support; all Guile scripting
+ tests PASS). So, probably some bad interaction between GDB and a debuggee
+ that is using libgc; maybe libgc is using SIGSEGV for internal signalling
+ purposes; see the `HEURISTIC2` discussion on [[boehm_gc]].
+
+ #0 0x0126b961 in GC_find_limit_with_bound () from /usr/lib/i386-gnu/libgc.so.1
+ #1 0x0126ba2e in GC_find_limit () from /usr/lib/i386-gnu/libgc.so.1
+ #2 0x0126bb15 in GC_get_stack_base () from /usr/lib/i386-gnu/libgc.so.1
+ #3 0x011be0ec in scm_init_guile () from /usr/lib/libguile-2.0.so.22
+ #4 0x081203ba in _initialize_guile () at ../../W._C._Handy/gdb/guile/guile.c:704
+ #5 0x082dc94d in initialize_all_files () at init.c:291
+ #6 0x082a3c7f in gdb_init (argv0=0x8563e90 "[...]/gdb/testsuite/gdb.gdb/xgdb") at ../../W._C._Handy/gdb/top.c:1822
+ #7 0x081da3b8 in captured_main (data=0x1bff164) at ../../W._C._Handy/gdb/main.c:747
+ #8 0x081d70e9 in catch_errors (func=func@entry=0x81da110 <captured_main>, func_args=func_args@entry=0x1bff164, errstring=errstring@entry=0x837a0e5 "", mask=mask@entry=RETURN_MASK_ALL) at ../../W._C._Handy/gdb/exceptions.c:524
+ #9 0x081db277 in gdb_main (args=0x1bff164) at ../../W._C._Handy/gdb/main.c:1062
+ #10 0x0809714b in main (argc=5, argv=0x1bff1f4) at ../../W._C._Handy/gdb/gdb.c:33
+
+ TODO.
+
+TODO.
+
+
+# Open Issues
+
+## [[tag/open_issue_binutils]]
+
+## [[tag/open_issue_gdb]]
+
+## GDB `info files` SIGSEGV
+
+[[!tag open_issue_gdb]]
+
+
+### IRC, freenode, #hurd, 2013-09-07
+
+ <rekado> I'm trying to debug pfinet, but I'm not very familiar with gdb.
+ Tried to attach to the running pfinet process (built with debug symbols),
+ set a breakpoint and ... when I ran "info files" the process segfaulted.
+ <teythoon> which process segfaults, pfinet or gdb?
+ <rekado> gdb segfaults.
+
+
+## GDB Watchpoints
+
+[[!tag open_issue_gdb]]
+
+
+### IRC, freenode, #hurd, 2013-09-16
+
+ <gnu_srs> tschwinge: Is gdb watch known to fail on hurd? It hangs for me
+ when logged in via ssh.
+ <tschwinge> gnu_srs: Don't know about GDB's watch command. Are you sure it
+ is hanging?
diff --git a/open_issues/blkrrpart_ioctl.mdwn b/open_issues/blkrrpart_ioctl.mdwn
new file mode 100644
index 00000000..b3a91bfb
--- /dev/null
+++ b/open_issues/blkrrpart_ioctl.mdwn
@@ -0,0 +1,32 @@
+[[!meta copyright="Copyright © 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="BLKRRPART IOCTL"]]
+
+[[!tag open_issue_glibc open_issue_hurd open_issue_gnumach]]
+
+Just like in other Unix systems one can, for example, use `fdisk` or `parted`
+to manage hard disks' partition tables. After doing changes to a disk's
+partition table, the kernel has to be instructed to reinitialize its internal
+data structures: where does a partition begin, where does it end, etc.
+
+With `fdisk` and friends this is done on Linux with the `BLKRRPART` IOCTL,
+which is used to tell the kernel to reread the disk's partition table.
+
+`parted` also uses this interface on Linux, but for GNU Hurd, the corresponding
+function, `libparted/arch/gnu.c (gnu_disk_commit)`, doesn't do anything at all.
+The infrastructure in [[GNU_Mach|microkernel/mach/gnumach]] is already there,
+`linux/src/drivers/block/ide.c (ide_ioctl) <BLKRRPART>` and
+`linux/src/drivers/scsi/sd_ioctl.c (sd_ioctl) <BLKRRPART>`, but the IOCTL needs
+to be routed from `libparted` through [[hurd/glibc]]'s Hurd IOCTL interface,
+through Hurd's [[hurd/libstore]], to [[GNU_Mach|microkernel/mach/gnumach]].
+
+This is not a huge project, and actually one that is suitable for someone who
+wants to start with hacking the system.
diff --git a/open_issues/boehm_gc.mdwn b/open_issues/boehm_gc.mdwn
new file mode 100644
index 00000000..2913eea8
--- /dev/null
+++ b/open_issues/boehm_gc.mdwn
@@ -0,0 +1,553 @@
+[[!meta copyright="Copyright © 2010, 2012, 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]]."]]"""]]
+
+Here's what's to be done for maintaining Boehm GC.
+
+This one does need Hurd-specific configuration.
+
+It is, for example, used by [[/GCC]] (which has its own fork), so any changes
+committed upstream should very like also be made there.
+
+[[!toc levels=2]]
+
+
+# [[General information|/boehm_gc]]
+
+
+# Configuration
+
+<!--
+
+git checkout reviewed
+git log --reverse --pretty=fuller --stat=$COLUMNS,$COLUMNS -w -p -C --cc ..upstream/master
+-i
+/^commit |^---$|hurd|linux|glibc
+
+-->
+
+Last reviewed up to the 5f492b98dd131bdd6c67eb56c31024420c1e7dab (2012-06-08)
+sources, and for `libatomic_ops` to the
+6a0afde033f105c6320f1409162e3765a1395bfd (2012-05-15) sources.
+
+ * `configure.ac`
+
+ * `PARALLEL_MARK` is not enabled; doesn't make sense so far.
+
+ * `*-*-kfreebsd*-gnu` defines `USE_COMPILER_TLS`. What's this, and
+ why does not other config?
+
+ * TODO
+
+ [ if test "$enable_gc_debug" = "yes"; then
+ AC_MSG_WARN("Should define GC_DEBUG and use debug alloc. in clients.")
+ AC_DEFINE([KEEP_BACK_PTRS], 1,
+ [Define to save back-pointers in debugging headers.])
+ keep_back_ptrs=true
+ AC_DEFINE([DBG_HDRS_ALL], 1,
+ [Define to force debug headers on all objects.])
+ case $host in
+ x86-*-linux* | i586-*-linux* | i686-*-linux* | x86_64-*-linux* )
+ AC_DEFINE(MAKE_BACK_GRAPH)
+ AC_MSG_WARN("Client must not use -fomit-frame-pointer.")
+ AC_DEFINE(SAVE_CALL_COUNT, 8)
+ ;;
+ AM_CONDITIONAL([KEEP_BACK_PTRS], [test x"$keep_back_ptrs" = xtrue])
+
+ * `configure.host`
+
+ Nothing.
+
+ * `Makefile.am`, `include/include.am`, `cord/cord.am`, `doc/doc.am`,
+ `tests/tests.am`
+
+ Nothing.
+
+ * `include/gc_config_macros.h`
+
+ Should be OK.
+
+ * `include/private/gcconfig.h`
+
+ Hairy. But should be OK. Search for *HURD*, compare to *LINUX*,
+ *I386* case.
+
+ See `doc/porting.html` and `doc/README.macros` (and others) for
+ documentation.
+
+ *LINUX* has:
+
+ * `#define LINUX_STACKBOTTOM`
+
+ Defined instead of `STACKBOTTOM` to have the value read from `/proc/`.
+
+ * `#define HEAP_START (ptr_t)0x1000`
+
+ May want to define it for us, too?
+
+ * `#ifdef USE_I686_PREFETCH`, `USE_3DNOW_PREFETCH` --- [...]
+
+ Apparently these are optimization that we also could use. Have a
+ look at *LINUX* for *X86_64*, which uses `__builtin_prefetch`
+ (which Linux x86 could use, too?).
+
+ * TODO
+
+ #if defined(LINUX) && defined(USE_MMAP)
+ /* The kernel may do a somewhat better job merging mappings etc. */
+ /* with anonymous mappings. */
+ # define USE_MMAP_ANON
+ #endif
+
+ * TODO
+
+ #if defined(GC_LINUX_THREADS) && defined(REDIRECT_MALLOC)
+ /* Nptl allocates thread stacks with mmap, which is fine. But it */
+ /* keeps a cache of thread stacks. Thread stacks contain the */
+ /* thread control blocks. These in turn contain a pointer to */
+ /* (sizeof (void *) from the beginning of) the dtv for thread-local */
+ /* storage, which is calloc allocated. If we don't scan the cached */
+ /* thread stacks, we appear to lose the dtv. This tends to */
+ /* result in something that looks like a bogus dtv count, which */
+ /* tends to result in a memset call on a block that is way too */
+ /* large. Sometimes we're lucky and the process just dies ... */
+ /* There seems to be a similar issue with some other memory */
+ /* allocated by the dynamic loader. */
+ /* This should be avoidable by either: */
+ /* - Defining USE_PROC_FOR_LIBRARIES here. */
+ /* That performs very poorly, precisely because we end up */
+ /* scanning cached stacks. */
+ /* - Have calloc look at its callers. */
+ /* In spite of the fact that it is gross and disgusting. */
+ /* In fact neither seems to suffice, probably in part because */
+ /* even with USE_PROC_FOR_LIBRARIES, we don't scan parts of stack */
+ /* segments that appear to be out of bounds. Thus we actually */
+ /* do both, which seems to yield the best results. */
+
+ # define USE_PROC_FOR_LIBRARIES
+ #endif
+
+ * TODO
+
+ # if defined(GC_LINUX_THREADS) && defined(REDIRECT_MALLOC) \
+ && !defined(INCLUDE_LINUX_THREAD_DESCR)
+ /* Will not work, since libc and the dynamic loader use thread */
+ /* locals, sometimes as the only reference. */
+ # define INCLUDE_LINUX_THREAD_DESCR
+ # endif
+
+ * TODO
+
+ # if defined(UNIX_LIKE) && defined(THREADS) && !defined(NO_CANCEL_SAFE) \
+ && !defined(PLATFORM_ANDROID)
+ /* Make the code cancellation-safe. This basically means that we */
+ /* ensure that cancellation requests are ignored while we are in */
+ /* the collector. This applies only to Posix deferred cancellation;*/
+ /* we don't handle Posix asynchronous cancellation. */
+ /* Note that this only works if pthread_setcancelstate is */
+ /* async-signal-safe, at least in the absence of asynchronous */
+ /* cancellation. This appears to be true for the glibc version, */
+ /* though it is not documented. Without that assumption, there */
+ /* seems to be no way to safely wait in a signal handler, which */
+ /* we need to do for thread suspension. */
+ /* Also note that little other code appears to be cancellation-safe.*/
+ /* Hence it may make sense to turn this off for performance. */
+ # define CANCEL_SAFE
+ # endif
+
+ * `CAN_SAVE_CALL_ARGS` vs. -fomit-frame-pointer now being on by
+ default for Linux x86 IIRC? (Which is an [[!taglink
+ open_issue_gcc]] for not including us.)
+
+ * TODO
+
+ # if defined(REDIRECT_MALLOC) && defined(THREADS) && !defined(LINUX)
+ # error "REDIRECT_MALLOC with THREADS works at most on Linux."
+ # endif
+
+
+ *HURD* has:
+
+ * `#define STACK_GROWS_DOWN`
+
+ * `#define HEURISTIC2`
+
+ Defined instead of `STACKBOTTOM` to have the value probed.
+
+ Linux also has this:
+
+ #if defined(LINUX_STACKBOTTOM) && defined(NO_PROC_STAT) \
+ && !defined(USE_LIBC_PRIVATES)
+ /* This combination will fail, since we have no way to get */
+ /* the stack base. Use HEURISTIC2 instead. */
+ # undef LINUX_STACKBOTTOM
+ # define HEURISTIC2
+ /* This may still fail on some architectures like IA64. */
+ /* We tried ... */
+ #endif
+
+ Being on [[glibc]], we could perhaps do similar as `USE_LIBC_PRIVATES`
+ instead of `HEURISTIC2`. Pro: avoid `SIGSEGV` (and general fragility)
+ during probing at startup (if I'm understanding this correctly). Con:
+ rely on glibc internals. Or we instead add support to parse
+ [[`/proc/`|hurd/translator/procfs]] (can even use the same as Linux?),
+ or use some other interface. [[!tag open_issue_glibc]]
+ This is also likely the issue causing the GDB [[!tag open_issue_gdb]]
+ `GC_find_limit_with_bound` SIGSEGV startup confusion described in
+ [[binutils]].
+
+ * `#define SIG_SUSPEND SIGUSR1`, `#define SIG_THR_RESTART SIGUSR2`
+
+ * We don't `#define MPROTECT_VDB` (WIP comment); but Linux neither.
+
+ * Where does our `GETPAGESIZE` come from? Should we `#include
+ <unistd.h>` like it is done for *LINUX*?
+
+ * `include/gc_pthread_redirects.h`
+
+ * TODO
+
+ Cancellation stuff is Linux-only. In other places, too.
+
+ * `mach_dep.c`
+
+ * `#define NO_GETCONTEXT`
+
+ [[!taglink open_issue_glibc]], but this is not a real problem here,
+ because we can use the following GCC internal function without much
+ overhead:
+
+ * `GC_with_callee_saves_pushed`
+
+ The `HAVE_BUILTIN_UNWIND_INIT` case is ours.
+
+ * `os_dep.c`
+
+ * `read`
+
+ Sure that it doesn't internally (in [[glibc]]) use `malloc`. Probably
+ only / mostly (?) a problem for `--enable-redirect-malloc`
+ configurations? Linux with threads uses `readv`.
+
+ * TODO.
+
+ * `dyn_load.c`
+
+ For `DYNAMIC_LOADING`. TODO.
+
+ * `pthread_support.c`, `pthread_stop_world.c`
+
+ TODO.
+
+ * TODO.
+
+ Other files also contain *LINUX* and other conditionals.
+
+ * `libatomic_ops/`
+
+ * `configure.ac`
+
+ Nothing.
+
+ * `Makefile`, `src/Makefile`, `src/atomic_ops/Makefile`,
+ `src/atomic_ops/sysdeps/Makefile`, `doc/Makefile`, `tests/Makefile`
+
+ Nothing.
+
+ * `src/atomic_ops/sysdeps/gcc/x86.h`
+
+ Nothing.
+
+ * b8b65e8a5c2c4896728cd00d008168a6293f55b1 configure.ac probably not all
+ correct.
+
+ * `mmap`, b64dd3bc1e5a23e677c96b478d55648a0730ab75
+
+ * `parallel mark`, 07c2b8e455c9e70d1f173475bbf1196320812154, pass
+ `--disable-parallel-mark` or enable for us, too?
+
+ * `HANDLE_FORK`, e9b11b6655c45ad3ab3326707aa31567a767134b,
+ 806d656802a1e3c2b55cd9e4530c6420340886c9,
+ 1e882b98c2cf9479a9cd08a67439dab7f9622924
+
+ * Check `include/private/thread_local_alloc.h` re
+ `USE_COMPILER_TLS`/`USE_PTHREAD_SPECIFIC`.
+
+
+# Build
+
+Here's a log of a binutils build run; this is from the
+5f492b98dd131bdd6c67eb56c31024420c1e7dab (2012-06-08) sources, and for
+`libatomic_ops` for the 6a0afde033f105c6320f1409162e3765a1395bfd (2012-05-15)
+sources, run on kepler.SCHWINGE and coulomb.SCHWINGE.
+
+ $ export LC_ALL=C
+ $ (cd ../master/ && ln -sfn ../libatomic_ops/master libatomic_ops)
+ $ (cd ../master/ && autoreconf -vfi)
+ $ ../master/configure --prefix="$PWD".install SHELL=/bin/bash CC=gcc-4.6 CXX=g++-4.6 --enable-cplusplus --enable-gc-debug --enable-gc-assertions --enable-assertions 2>&1 | tee log_build
+ [...]
+ $ make 2>&1 | tee log_build_
+ [...]
+
+Different hosts may default to different shells and compiler versions; thus
+harmonized. Using bash instead of dash as otherwise libtool explodes.
+
+This takes up around X MiB, and needs roughly X min on kepler.SCHWINGE and
+X min on coulomb.SCHWINGE.
+
+<!--
+
+ $ (make && touch .go-install) 2>&1 | tee log_build_ && test -f .go-install && (make install && touch .go-check) 2>&1 | tee log_install && test -f .go-check && { make -k check 2>&1 | tee log_check; (cd libatomic_ops/ && make -k check) 2>&1 | tee log_check_; }
+
+-->
+
+## Analysis
+
+ $ ssh kepler.SCHWINGE 'cd tmp/source/boehm-gc/ && cat master.build/log_build* | sed -e "s%\(/media/data\)\?${PWD}%[...]%g"' > toolchain/logs/boehm-gc/linux/log_build
+ $ ssh coulomb.SCHWINGE 'cd tmp/boehm-gc/ && cat master.build/log_build* | sed -e "s%\(/media/erich\)\?${PWD}%[...]%g"' > toolchain/logs/boehm-gc/hurd/log_build
+ $ diff -wu <(sed -f toolchain/logs/boehm-gc/linux/log_build.sed < toolchain/logs/boehm-gc/linux/log_build) <(sed -f toolchain/logs/boehm-gc/hurd/log_build.sed < toolchain/logs/boehm-gc/hurd/log_build) > toolchain/logs/boehm-gc/log_build.diff
+
+ * only GNU/Linux: `configure: WARNING: "Explicit GC_INIT() calls may be
+ required."`
+
+ * only GNU/Linux: `configure: WARNING: "Client must not use
+ -fomit-frame-pointer."`
+
+
+# Install
+
+ $ make install 2>&1 | tee log_install
+ [...]
+
+This takes up around X MiB, and needs roughly X min on kepler.SCHWINGE and X
+min on coulomb.SCHWINGE.
+
+
+## Analysis
+
+ $ ssh kepler.SCHWINGE 'cd tmp/source/boehm-gc/ && cat master.build/log_install | sed -e "s%\(/media/data\)\?${PWD}%[...]%g"' > toolchain/logs/boehm-gc/linux/log_install
+ $ ssh coulomb.SCHWINGE 'cd tmp/boehm-gc/ && cat master.build/log_install | sed -e "s%\(/media/erich\)\?${PWD}%[...]%g"' > toolchain/logs/boehm-gc/hurd/log_install
+ $ diff -wu toolchain/logs/boehm-gc/linux/log_install toolchain/logs/boehm-gc/hurd/log_install > toolchain/logs/boehm-gc/log_install.diff
+
+
+# Testsuite
+
+ $ make -k check
+ [...]
+ $ (cd libatomic_ops/ && make -k check)
+ [...]
+
+This needs roughly X min on kepler.SCHWINGE and X min on coulomb.SCHWINGE.
+
+
+## Analysis
+
+ $ ssh kepler.SCHWINGE 'cd tmp/source/boehm-gc/ && cat master.build/log_check* | sed -e "s%\(/media/data\)\?${PWD}%[...]%g"' > toolchain/logs/boehm-gc/linux/log_check
+ $ ssh coulomb.SCHWINGE 'cd tmp/boehm-gc/ && cat master.build/log_check* | sed -e "s%\(/media/erich\)\?${PWD}%[...]%g"' > toolchain/logs/boehm-gc/hurd/log_check
+ $ diff -wu <(sed -f toolchain/logs/boehm-gc/linux/log_check.sed < toolchain/logs/boehm-gc/linux/log_check) <(sed -f toolchain/logs/boehm-gc/hurd/log_check.sed < toolchain/logs/boehm-gc/hurd/log_check) > toolchain/logs/boehm-gc/log_check.diff
+
+There are different configurations possible, but in general, the testsuite
+restults of GNU/Linux and GNU/Hurd look very similar.
+
+ * GNU/Hurd is missing `Call chain at allocation: [...]` output.
+
+ `os_dep.c`:`GC_print_callers`
+
+
+# TODO
+
+ * What are other applications to test Boehm GC? Also especially in
+ combination with [[/libpthread]] and dynamic loading of shared libraries?
+
+ * There are patches (apparently not committed) that GCC itself can use
+ it, too: <http://gcc.gnu.org/wiki/Garbage_collection_tuning>.
+
+ * There's been some talking about it on GNU guile mailing lists, and two
+ Git branches (2010-12-15: last change 2009-09).
+
+ * <http://www.hpl.hp.com/personal/Hans_Boehm/gc/#users>
+
+
+## IRC, OFTC, #debian-hurd, 2012-02-05
+
+[[!tag open_issue_porting]]
+
+ <pinotree> youpi: i think i found out the possible cause of the ecl and
+ mono issuess
+ <pinotree> -s
+ <youpi> oh
+ <pinotree> basically, we don't have the realtime signals (so no
+ SIGRTMIN/SIGRTMAX defined), hence things use either SIGUSR1 or
+ SIGUSR2... which are used in libgc to resp. stop/resume threads when
+ "collecting"
+ <pinotree> i just patched ecl to use SIGINFO instead of SIGUSR1 (used when
+ no SIGRTMIN+2 is available), and it seems going on for a while
+ <youpi> uh, why would SIGINFO work better than SIGUSR1?
+ <pinotree> it was a test, i tried the first "not common" signal i saw
+ <pinotree> my test was, use any signal different than USR1/2
+ <youpi> ah, sorry, I hadn't understood
+ <youpi> you mean there's a conflict between ecl and mono using SIGUSR1, as
+ well as libgc?
+ <pinotree> yes
+ <pinotree> for example, in ecl sources see src/c/unixint.d,
+ install_process_interrupt_handler()
+ <youpi> SIGINFO seems a sane choice
+ <youpi> SIGPWR could have been a better choice if it was available :)
+ <pinotree> i would have chose an "unassigned" number, say SIGLOST (the
+ bigger one) + 10, but it would be greater than _NSIG (and thus discarded)
+ <youpi> not a good idea indeed
+ <pinotree> it seems that linux, beside the range for rt signals, has some
+ "free space"
+ <pinotree> i'll start now another ecl build, from scratch this time, with
+ s/SIGUSR1/SIGINFO/ (making sure ctags won't bother), and if it works i'll
+ update svante's bug
+
+ <pinotree> mmap(...PROT_NONE...) failed
+ <pinotree> hmm...
+ <pinotree> apparently enabling MMAP_ANON in mono's libgc copy was a good
+ step, let's see
+
+
+### IRC, OFTC, #debian-hurd, 2012-03-18
+
+ <pinotree> youpi: mono is afflicted by the SIGUSR1/2 conflict with libgc
+ <youpi> pinotree: didn't we have a solution for that?
+ <pinotree> well, it works just for one signal
+ <pinotree> the ideal solution would be having a range for RT signals, and
+ make libgc use RTMIN+5/6, like done on most of other OSes
+ <youpi> but we don't have RT signals, do we?
+ <pinotree> right :(
+
+
+### IRC, freenode, #hurd, 2012-03-21
+
+ <pinotree> civodul: given we have to realtime signals (so no range of
+ signals for them), libgc uses SIGUSR1/2 instead of using SIGRTMIN+5/6 for
+ its thread synchronization stuff
+ <pinotree> civodul: which means that if an application using libgc then
+ sets its own handlers for either of SIGUSR1/2, hell breaks
+ <civodul> pinotree: ok
+ <civodul> pinotree: is it a Debian-specific change, or included upstream?
+ <pinotree> libgc using SIGUSR1/2? upstream
+ <civodul> ok
+
+
+### IRC, freenode, #hurd, 2013-09-03
+
+ <congzhang> braunr: when will libc malloc say memory corruption?
+ <braunr> congzhang: usually on free
+ <braunr> sometimes on alloc
+ <congzhang> and after one thread be created
+ <congzhang> I want to know why and how to find the source
+ <congzhang> does libgc work well on hurd?
+ <braunr> i don't think it does
+ <congzhang> so , why it can't?
+ <braunr> congzhang: what ?
+ <congzhang> libgc was not work on hurd
+ <pinotree> why?
+ <congzhang> I try porting dotgnu
+ <braunr> ah
+ <braunr> nested signal handling
+ <congzhang> one program always receive Abort signal
+ <pinotree> and why it should be a problem in libgc?
+ <congzhang> for malloc memory corruption
+ <braunr> libgc relies on this
+ <congzhang> yes
+ <congzhang> so, is there a workaround to make it work?
+ <braunr> show the error please
+ <congzhang> http://paste.debian.net/34416/
+ <pinotree> where's libgc?
+ <congzhang> i compile dotgnu with enable-gc
+ <pinotree> so?
+ <congzhang> I am not sure about it
+ <pinotree> so why did you say earlier that libgc doesn't work?
+ <congzhang> because after I see one thread was created notice by gdb, it
+ memory corruption
+ <pinotree> so what?
+ <congzhang> maybe gabage collection happen, and gc thread start
+ <pinotree> that's speculation
+ <pinotree> you cannot debug things speculating on code you don't know
+ <pinotree> less speculation and more in-deep debugging, please
+ * congzhang I try again, to check weather thread list changing
+ <congzhang> sorry for this
+ <braunr> it simply looks like a real memory corruption (an overflow)
+ <congzhang> maybe PATH related problem
+ <pinotree> PATH?
+ <congzhang> yes
+ <braunr> PATH_MAX
+ <braunr> but unlikely
+ <congzhang> csant do path traverse
+ <congzhang> I fond the macro
+ <congzhang> found
+ <congzhang> #if defined(__sun__) || defined(__BEOS__)
+ <congzhang> #define BROKEN_DIRENT 1
+ <congzhang> #endif
+ <congzhang> and so for hurd?
+ <pinotree> BROKEN_DIRENT doesn't say much about what it does
+ <WhiteKIBA> nope
+ <WhiteKIBA> whoops
+ <congzhang> it seems other port meet the trouble too
+ <pinotree> which trouble?
+ <congzhang> http://comments.gmane.org/gmane.comp.gnu.dotgnu.developer/3642
+ <congzhang> (gdb) ptype struct dirent
+ <congzhang> type = struct dirent {
+ <congzhang> __ino_t d_ino;
+ <congzhang> unsigned short d_reclen;
+ <congzhang> unsigned char d_type;
+ <congzhang> unsigned char d_namlen;
+ <congzhang> char d_name[1];
+ <congzhang> }
+ <congzhang>
+ <congzhang> d_name should be char[PATH_MAX]?
+ <congzhang> and
+ http://libjit-linear-scan-register-allocator.googlecode.com/svn/trunk/pnet/support/dir.c
+ <pinotree> no
+ <braunr> stop pasting that much
+ <_d3f> uhm PATH_MAX on the hurd?
+ <braunr> and stop saying nonsense
+ <congzhang> sorry, i think four line was not worth to pastbin
+ <pinotree> they are 8
+ <congzhang> never again
+ <braunr> just try by defining BROKEN_DIRENT to 1 in all cases and see how
+ it goes
+ * congzhang read dir.c again
+ <congzhang> braunr: it does not crash this time, I do more test
+
+
+#### IRC, freenode, #hurd, 2013-09-04
+
+ <congzhang> hi, I am dotgnu work on hurd, and even winforms app
+ <congzhang> s/am/make
+ <congzhang> and maybe c# hello world translate another day :)
+
+
+### IRC, freenode, #hurd, 2013-12-16
+
+ <braunr> gnu_srs: ah, libgc
+ <braunr> there are signal-related problems with libgc
+
+
+## Leak Detection
+
+### IRC, freenode, #hurd, 2013-10-17
+
+ <teythoon> I spent the last two days integrating libgc - the boehm
+ conservative garbage collector - into hurd
+ <teythoon> it can be used in leak detection mode
+ <azeem> whoa, cool
+ <teythoon> and it actually kind of works, finds malloc leaks in translators
+ <braunr> i think there were problems with signal handling in libgc
+ <braunr> i'm not sure we support nested signal handling well
+ <teythoon> yes, I read about them
+ <teythoon> libgc uses SIGUSR1/2, so any program installing handlers on them
+ will break
+ <azeem> (which is not a problem on Linux, cause there some RT-signals or so
+ are used)
+ <teythoon> yes
diff --git a/open_issues/bpf.mdwn b/open_issues/bpf.mdwn
new file mode 100644
index 00000000..d051c2d8
--- /dev/null
+++ b/open_issues/bpf.mdwn
@@ -0,0 +1,654 @@
+[[!meta copyright="Copyright © 2009, 2012, 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]]."]]"""]]
+
+[[!meta title=BPF]]
+
+[[!tag open_issue_gnumach open_issue_hurd]]
+
+This is a collection of resources concerning *Berkeley Packet Filter*s.
+
+
+# Documentation
+
+ * Wikipedia: [[!wikipedia "Berkeley Packet Filter"]]
+
+ * [The Packet Filter: An Efficient Mechanism for User-level Network
+ Code](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.36.8755),
+ 1987, Jeffrey C. Mogul, Richard F. Rashid, Michael J. Accetta
+
+ * [The BSD Packet Filter: A New Architecture for User-level Packet
+ Capture](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.43.7849),
+ 1992, Steven Mccanne, Van Jacobson
+
+ * [Protocol Service Decomposition for High-Performance
+ Networking](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.30.8387),
+ 1993, Chris Maeda, Brian N. Bershad
+
+ * [Efficient Packet Demultiplexing for Multiple Endpoints and Large
+ Messages](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.46.44),
+ 1994, Masanobu Yuhara Fujitsu, Masanobu Yuhara, Brian N. Bershad, Chris
+ Maeda, J. Eliot, B. Moss
+
+ * ... and many more
+
+
+# Implementation
+
+ * [[community/HurdFr]]
+
+ * <http://wiki.hurdfr.org/index.php/BPF>
+
+ * <http://wiki.hurdfr.org/index.php/Reseau_dans_gnumach>
+
+ * Git repository: <http://rcs-git.duckcorp.org/hurdfr/bpf.git/>
+
+ The patch for [[GNU Mach|microkernel/mach/gnumach]] is expected to be
+ complete and functional, the [[hurd/translator]] less so -- amongst others,
+ there are unresolved issues concerning support of [[hurd/glibc/IOCTL]]s.
+
+ * <http://lists.gnu.org/archive/html/bug-hurd/2006-03/msg00025.html>
+
+ * [[zhengda]]
+
+ * [[!GNU_Savannah_bug 25054]] -- Kernel panic with eth-multiplexer
+
+ * [[!GNU_Savannah_patch 6619]] -- pfinet uses the virtual interface
+
+ * [[!GNU_Savannah_patch 6620]] -- pfinet changes its filter rules with
+ its IP address
+
+ * [[!GNU_Savannah_patch 6621]] -- pfinet sets the mach device into the
+ promiscuous mode
+
+ * [[!GNU_Savannah_patch 6622]] -- pfinet uses the BPF filter
+
+ * [[!GNU_Savannah_patch 6851]] -- fix a bug in BPF
+
+
+# IRC
+
+## IRC, freenode, #hurd, 2012-01-13
+
+ <braunr> hm, i think the bpf code needs a complete redesign :p
+ <braunr> unless it's actually a true hurdish way to do things
+ <braunr> antrik: i need your help :)
+ <braunr> antrik: I need advice on the bpf "architecture"
+ <braunr> the current implementation uses a translator installed at /dev/bpf
+ <braunr> which means packets from the kernel are copied to that translator
+ and then to client applications
+ <braunr> does that seem ok to you ?
+ <braunr> couldn't the translator be used to set a direct link between the
+ kernel and the client app ?
+ <braunr> which approach seems the more Hurdish to you ? (<= this is what I
+ need your help on)
+ <pinotree> braunr: so there would be a roundtrip like kernel → bpf
+ translator → pfinet?
+ <antrik> braunr: TBH, I don't see why we need a BPF translator at all...
+ <braunr> antrik: it handles the ioctls
+ <braunr> pinotree: pfinet isn't involved (it was merely modified to use the
+ "new" filter format to specify it used the old packet filter, and not
+ bpf)
+ <antrik> braunr: do we really need to emulate the ioctl()s? can't we assume
+ that all packages using BPF will just use libpcap?
+ <antrik> (and even if we *do* want to emulate ioctl()s, why can't we handle
+ this is libc?)
+ <braunr> antrik: that's what i'm wondering actually
+ <braunr> even if assuming all packages use libpcap, i'd like our bpf
+ interface to be close to what bsds have, and most importantly, what
+ libpcap expects from a bpf interface
+ <antrik> well, why? if we already have a library handling the abstraction,
+ I don't see much point in complicating the design and use by adding
+ another layer :-)
+ <braunr> so you would advise adapting libpcap to include a hurd specific
+ module ?
+ <antrik> there are two reasons for adding translators: more robustness or
+ more flexibility... so far I don't see how a BPF translator would add
+ either
+ <braunr> right
+ <antrik> yes
+ <braunr> so we'd end up with a bpf-like interface, the same instructions
+ and format, with different control calls
+ <antrik> right
+ <antrik> note that I had more or less the same desicion to make for KGI
+ (emulate Linux/BSD ioctl()s, or implement a backend in libggi for
+ handling Hurd-specific RPC; and after much consideration, I decided on
+ the latter)
+
+
+## IRC, freenode, #hurd, 2012-01-16
+
+ <braunr> antrik: is there an existing facility to easily give a send right
+ to the device master port to a task ?
+ <braunr> another function of the bpf translator is to handle the /dev/bpf
+ node, and most importantly its permissions
+ <braunr> so that users which have read/write access to the node have access
+ to the packet filter
+ <braunr> i guess the translator could limit itself to that functionality
+ <braunr> and then provide a device port on which libpcap operates directly
+ by means of device_{g,s}et_status/device_set_filter
+ <antrik> braunr: I don't see the point in seperating permissions for filter
+ from permissions from general network device access...
+ <antrik> as for device master port, all root tasks can obtain it from proc
+ IIRC
+ <braunr> antrik: yes, but how do we allow non-root users to access that
+ facility ?
+ <braunr> on a unix like system, it's a matter of changing the permissions
+ of /dev/bpf
+ <antrik> with devnode, non-root users can get access to specific device
+ nodes, including network devices
+ <braunr> i can't imagine the hurd being less flexible for that
+ <braunr> ah devnode
+ <braunr> good
+ <antrik> so we can for example make /dev/eth0 accessible by users of some
+ group
+ <braunr> what's devnode exactly ?
+ <antrik> it's a very simple translator that implements an FS node that
+ looks somewhat like a file, but the only operation it supports is
+ obtaining a pseudo device master port, giving access to a specific Mach
+ device
+ <braunr> is it already part of the hurd ?
+ <braunr> or hurdextras maybe ?
+ <antrik> it's only in zhengda's branch
+ <braunr> ah
+ <antrik> needed for both eth-multipexer and DDE
+ <braunr> and bpf soon i guess
+ <antrik> indeed :-)
+ <braunr> "obtaining a pseudo device master port", i believe you meant a
+ pseudo device port
+ <antrik> I must admit that I don't remember exactly whether devnode proxies
+ device_open(), so clients direct get a port to the device in question, or
+ whether it implements a pseudo device master port...
+ <antrik> but definitely not a pseudo device port :-)
+ <braunr> i'm almost positive it gives the target device port, otherwise i
+ don't see the point
+ <braunr> i don't understand the user of the "pseudo" word here either
+ <braunr> s/user/use/
+ <braunr> aiui, devnode should be started as root (or in any way which gives
+ it the device master port)
+ <antrik> the point is that the client doesn't need to know the Mach device
+ name, and also is not bound to actual kernel devices
+ <braunr> and when started, implement the required permissions before giving
+ clients a device port to the specific device it was installed for
+ <braunr> right
+ <braunr> but it mustn't be a proxy
+ <antrik> yes, devnode needs access to either the real master device port
+ (for kernel devices), or one provided by eth-multiplexer or the DDE
+ network driver
+ <braunr> well, a very simple proxy for deviceopen
+ <braunr> ok
+ <braunr> that seems exactly what i wanted to do
+ <braunr> we now need to see if we can integrate it separately
+ <braunr> create a separate branch that works for the current gnumach code,
+ and merge dde/other specific code later on
+ <antrik> you mean independent of eth-multiplexer or DDE? yes, it was
+ generally agreed that devnode is a good idea in any case. I have no idea
+ why there are no device nodes for network devices on other UNIX
+ systems...
+ <braunr> i've been wondering that for years too :)
+ <antrik> zhengda's branch has a pfinet modified to a) use devnode, and b)
+ use BPF
+ <braunr> why bpf ?
+ <braunr> for more specific filters maybe ?
+ <antrik> hm... don't remember whether there was any technical reason for
+ going with BPF; I guess it just seemed more reasonable to invest new work
+ in BPF rather than obsolete Mach-specific NPF...
+ <braunr> cspf could be removed altogether, i agree
+ <antrik> another plus side of his modified pfinet is that it actually sets
+ an appropriate filter for TCP/IP and the IP in use, rather than just
+ setting a dummy filter catching app packets (including those irrelevant
+ to the specific pfinet instance)
+ <antrik> err... catching all packets
+ <braunr> that's what i meant by "for more specific filters maybe ?"
+ <braunr> he was probably more comfortable with the bpf interface to write
+ his filter rules
+ <antrik> well, it would probably be doable with NPF too :-) so by itself
+ it's not a reason for switching to BPF...
+ <antrik> it's rather the other way around: as it was necessary to implement
+ filters in eth-multiplexer, and implementing BPF seemed more reasoable,
+ pfinet had to be changed to use BPF...
+ <braunr> antrik: where is zhengda's branch btw ?
+ <antrik> (I guess using proper filters with eth-multiplexer is not strictly
+ necessary; but it would be a major performance hit not to)
+ <antrik> it's in incubator.git
+ <antrik> but it's very messy
+ <braunr> ok
+ <antrik> at some point I asked him to provide cleaned up branches, and I'm
+ pretty sure he said he did, but I totally fail to remember where he
+ published them :-(
+ <braunr> hm, i don't like how devnode is "architectured" :/
+ <braunr> but it makes things a little more easy to get working i guess
+ <LarstiQ> antrik: any idea what to grep the logs on for that?
+ <braunr> ok never mind, devnode is fine
+ <braunr> exactly what i need
+ <braunr> i wonder however if it shouldn't be improved to better handle
+ permissions
+ <braunr> ok, never mind either, permission handling is fine
+ <braunr> so what are we waiting for ? :)
+ <antrik> I remember that there were some issues with permission handling,
+ but I don't remember whether all were fixed :-(
+ <antrik> LarstiQ: hm... good question...
+ <braunr> ah ?
+ <braunr> hm actually, there could be issues for packet filters, yes
+ <braunr> i guess we want to allow e.g. read-only opens for capture only
+ <antrik> braunr: that would have to be handled by the actual BPF
+ implementation I'd say
+ <braunr> it should already be the case
+ <antrik> what's the problem then?
+ <braunr> but when the actual device_open() is performed, the appropriate
+ permissions must be provided
+ <braunr> and checking those is the responsibility of the proxy, devnode in
+ this case
+ <antrik> and it doesn't do that?
+ <braunr> apparently not
+ <braunr> the only check is against the device name
+ <braunr> i'll begin playing with that first
+ <antrik> I vaguely remember that there has been discussion about the
+ relation of underlying device open mode and devnode open mode... but I
+ don't remember the outcome. in fact it was probably one of the
+ discussions I never got around to follow up on... :-(
+ <antrik> before you begin playing, take a look at the relevant messages in
+ the ML archive :-)
+ <antrik> must have been around two years ago
+ <braunr> ok
+ <antrik> some thread with me and scolobb (Sergiu Ivanov +- spelling) and
+ probably zhengda
+ <antrik> there might also be some outstanding patch(es) from scolobb, not
+ sure
+
+
+## IRC, freenode, #hurd, 2012-01-17
+
+ <braunr> antrik: i think i found the thread you mentioned about devnode
+ <braunr> neither sergiu nor zhengda considered the use of a read-only
+ device for packet filtering
+ <braunr> leading to assumptions such as "only receiving packets
+ <braunr> is not terribly useful, in view of the fact that you have to at
+ least
+ <braunr> request them, which implies *sending* packets :-)
+ <braunr> "
+ <braunr> IMO, devnode should definitely check its node permissions to build
+ the device open flags
+ <braunr> good news is that it doesn't depend on anything specific to other
+ incubator projects
+ <braunr> making it almost readily mergeable in the hurd
+ <braunr> i'm not sure devnode is an appropriate name though
+ <braunr> maybe something like device, or devproxy
+ <braunr> proxy-devopen maybe
+ <antrik> braunr: well, I don't remember the details of the disucssion; but
+ as I mentioned in some mail, I did actually want to write a followup,
+ just didn't get around to it... so I was definitely not in agreement with
+ some of the statements made by others. I just don't remember on which
+ point :-)
+ <antrik> which thread was it?
+ <antrik> anyways, this should in no way be specific to network
+ devices... the idea is simply that if the client has only read
+ permissions on the device node, it should only get to open the underlying
+ device for read. it's up to the kernel to handle the read-only status for
+ the device once it's opened
+ <antrik> as for the naming, the idea is that devnode simply makes Mach
+ devices accessible through FS nodes... so the name seemed appropriate
+ <antrik> you may be right though that just "device" might be more
+ straightforward... I don't agree on the other variants
+ <braunr> antrik:
+ http://lists.gnu.org/archive/html/bug-hurd/2009-12/msg00155.html
+ <braunr> antrik: i agree with the general idea behind permission handling,
+ i was just referring to their thoughts about it, which probably led to
+ the hard coded READ | WRITE flags
+ <antrik> braunr: unfortunately, I don't remember the context of the
+ discussion... would take me a while to get into this again :-(
+ <antrik> the discussion seems to be about eth-multiplexer as much as about
+ devnode (if not more), and I don't remember the exact interaction
+
+
+## IRC, freenode, #hurd, 2012-01-18
+
+ <braunr> so, does anyone have an objection to getting devnode into the hurd
+ and calling it something else like e.g. device ?
+ <youpi> braunr: it's Zhengda's work, right?
+ <braunr> yes
+ <youpi> I'm completely for it, it just perhaps needs some cleanup
+ <braunr> i have a few changes to add to what already exists
+ <braunr> ok
+ <braunr> well i'm assigning myself to the task
+ <antrik> braunr: I'm still not convinced just "device" is preferable
+ <antrik> perhaps machdevice ;-)
+ <antrik> but otherwise, I'd LOVE to see it in :-)
+ <braunr> i don't know .. what if the device is actually eth-multiplexer or
+ a dde one ?
+ <braunr> it's not really "mach", is it ?
+ <braunr> or do we only refer to the interface ?
+ <youpi> that translator is only for mach devices
+ <braunr> so you consider dde devices as being mach devices too ?
+ <braunr> it's a simple proxy for device_open really
+ <youpi> will these devices use that translator?
+ <youpi> ah
+ <youpi> I thought it was using a mach-specific RPC
+ <braunr> so we can consider whatever we want
+ <antrik> braunr: yes, the translator is for Mach device interface only. it
+ might be provided by other servers, but it's still Mach devices
+ <youpi> then drop the mach, yes
+ <braunr> i'd tend to agree with antrik
+ <youpi> antrik: I'd say the device interface is part of the hur dinterfaces
+ <braunr> then machdev :p
+ <braunr> no, it's really part of the mach interface
+ <youpi> it's part of the mach interface, yes
+ <youpi> but also of the Hurd, no?
+ <antrik> DDE network servers also use the Mach device interface
+ <braunr> no
+ <youpi> can't we say it's part of it?
+ <youpi> I mean
+ <youpi> even if we change the kernel
+ <braunr> dde is the only thing that implements it besides the kernel that i
+ know of
+ <youpi> we will probably want to keep the same interface
+ <braunr> yes but that's a mach thing
+ <youpi> what we have now is not necessarily a reason
+ <antrik> as for other DDE drivers, I for my part believe they should export
+ proper Hurd (UNIX) device nodes directly... but for some reason zhengda
+ insisted on implementing it as Mach devices too :-(
+ <braunr> antrik: i agree with you on that too
+ <braunr> i was a bit surprised to see the same interface was reused
+ <braunr> youpi: we can, we just have to agree on what we'll do
+ <braunr> what do you mean by "even if we change the kernel" ?
+ <antrik> the problem with "machdev" is that it might suggest the translator
+ actually implements the device... not sure whether this would cause
+ serious confusion
+ <antrik> "devopen" might be another option
+ <antrik> or "machdevopen" to be entirely verbose ;-)
+ <braunr> an option i suggested earlier which you disagreed on :p
+ <braunr> but devopen is the one i'd choose
+ <antrik> youpi: as I already mentioned in the libburn thread, I don't
+ actually think the Mach device interface is very nice; IMHO we should get
+ rid of it as soon as we can, rather than port it to other
+ architectures...
+ <antrik> but even *if* we decided to reuse it after all, it would still be
+ the Mach device interface :-)
+ <braunr> actually, zheng da already suggested that name a long time ago
+ <braunr> http://lists.gnu.org/archive/html/bug-hurd/2008-08/msg00005.html
+ <braunr> no actually antrik did eh
+ <braunr> ok let's use devopen
+ <antrik> braunr: you suggested proxy-devopen, which I didn't like because
+ of the "proxy" part :-)
+ <braunr> not only, but i don't have the logs any more :p
+ <antrik> oh, I already suggested devopen once? didn't expect myself to be
+ that consistent... ;-)
+ <antrik> braunr: you suggested device, devproxy or proxy-devopen
+ <braunr> ah, ok
+ <braunr> devopen is better
+ <antrik> I wonder whether it's more important for clarity to have "mach" in
+ there or "open"... or whether it's really too unweildy to have both
+
+
+## IRC, freenode, #hurd, 2012-01-21
+
+ <braunr> oh btw, i made devopen run today, it shouldn't be hard getting it
+ in properly
+ <braunr> patching libpcap will be somewhat trickier
+ <braunr> i don't even really need it, but it allows having user access to
+ mach devices, which is nice for the libpcap patch and tcpdump tests
+ <braunr> permission checking is actually its only purpose
+ <braunr> well, no, not really, it also allows opening devices implemented
+ by user space servers transparently
+
+
+## IRC, freenode, #hurd, 2012-01-27
+
+ <braunr> hmm, bpf needs more work :(
+ <braunr> or we can use the userspace bpf filter in libpcap, so that it
+ works with both gnumach and dde drivers
+ <antrik> braunr: there is a userspace BPF implementation in libpcap? I'm
+ surprised that zhengda didn't notice it, and ported the one from gnumach
+ instead...
+ <antrik> what is missing in the kernel implementation?
+ <braunr> antrik: filling the bpf header
+ <braunr> frankly, i'm not sure we want to bother with the kernel
+ implementation
+ <braunr> i'd like it to work with both gnumach and dde drivers
+ <braunr> and in the long run, we'll be using userspace drivers anyway
+ <braunr> the bpf header was one of the things the defunct translator did
+ <braunr> which involved ugly memcpy()s :p
+ <antrik> braunr: well, if you want to get rid of the kernel implementation,
+ basically you would have to take up eth-multiplexer and get it into
+ mainline
+ <antrik> (and make sure it's used by default in Debian)
+ <antrik> I frankly believe it's the better design anyways... but quite a
+ major change :-)
+ <braunr> not that major to me
+ <braunr> in the meantime i'll use the libpcap embedded implementation
+ <braunr> we'll have something useful faster, with minimum work when
+ eth-multiplexer is available
+ <antrik> eth-multiplexer is ready for use, it just needs to go upstream
+ <antrik> though it's probably desirable to switch it to the BPF
+ implementation from libpcap
+ <braunr> using the libpcap implementation in libpcap and in eth-multiplexer
+ are two different things
+ <braunr> the latter is preferrable
+ <braunr> (and yes, by available, i meant upstream ofc)
+ <antrik> eth-mulitplexer is already using libpcap anyways (for compiling
+ the filters); I'm sure zhengda just didn't realize it has an actual BPF
+ implementation too...
+ <braunr> we want the filter implementation as close to the packet source as
+ possible
+ <antrik> I have been using eth-multiplexer for at least two years now
+ <braunr> hm, there is a "snoop" source type, using raw sockets
+ <braunr> too far from the packet source, but i'll try it anyway
+ <braunr> hm wrong, snoop was the solaris packet filter fyi
+
+
+## IRC, freenode, #hurd, 2012-01-28
+
+ <braunr> nice, i have tcpdump working :)
+ <braunr> let's see if it's as simple with wireshark
+ <pinotree> \o/
+ <braunr> pinotree: it was actually very simple
+ <pinotree> heh, POV ;)
+ <braunr> yep, wireshark works too
+ <braunr> promiscuous mode is harder to test :/
+ <braunr> but that's a start
+
+
+## IRC, freenode, #hurd, 2012-01-30
+
+ <braunr> ok so next step: get tcpreplay working
+ <antrik> braunr: BTW, when you checked the status of the kernel BPF code,
+ did you take zhengda's enhancements/fixes into account?...
+ <braunr> no
+ <braunr> when did i check it ?
+ <antrik> braunr: well, you said the kernel BPF code has serious
+ shortcomings. did you take zhengda's changes into account?
+ <braunr> antrik: ah, when i mention the issues, i considered the userspace
+ translator only
+ <braunr> antrik: and stuff like non blocking io, exporting a selectable
+ file descriptor
+ <braunr> antrik: deb http://ftp.sceen.net/debian-hurd experimental/
+ <braunr> antrik: this is my easy to use repository with a patched
+ libpcap0.8
+ <braunr> and a small and unoptimized pcap-hurd.c module
+ <braunr> it doesn't use devopen yet
+ <braunr> i thought it would be better to have packet filtering working
+ first as a debian patch, then get the new translator+final patch upstream
+ <jkoenig> braunr, tcpdump works great here (awesome!). I'm probably using
+ exactly the same setup and "hardware" as you do, though :-P
+
+
+## IRC, freenode, #hurd, 2012-01-31
+
+ <braunr> antrik: i tend to think we need a bpf translator, or anything
+ between the kernel and libpcap to provide selectable file descriptors
+ <braunr> jkoenig: do you happen to know how mach_msg (as called in a
+ hello.c file without special macros or options) deals with signals ?
+ <braunr> i mean, is it wrapped by the libc in a version that sets errno ?
+ <jkoenig> braunr: no idea.
+ <pinotree> braunr: what's up with it? (not that i have an idea about your
+ actual question, just curious)
+ <braunr> pinotree: i'm improving signal handling in my pcap-hurd module
+ <braunr> i guess checking for MACH_RCV_INTERRUPTED will dio
+ <braunr> -INFO is correctly handled :)
+ <braunr> ok new patch seems fine
+ <antrik> braunr: selectable file descriptors?
+ <braunr> antrik: see pcap_fileno() for example
+ <braunr> it returns a file descriptor matching the underlying object
+ (usually a socket) that can be multiplexed in a select/poll call
+ <braunr> obviously a mach port alone can't do the job
+ <braunr> i've upgraded the libpcap0.8 package with improved signal handling
+ for tests
+ <antrik> braunr: no idea what you are talking about :-(
+
+
+## IRC, freenode, #hurd, 2012-02-01
+
+ <braunr> antrik: you do know about select/poll
+ <braunr> antrik: you know they work with multiple selectable/pollable file
+ descriptors
+ <braunr> on most unix systems, packet capture sources are socket
+ descriptors
+ <braunr> they're selectable/pollable
+ <antrik> braunr: what are packet capture sources?
+ <braunr> antrik: objects that provide applications with packets :)
+ <braunr> antrik: a PF_PACKET socket on Linux for example, or a Mach device,
+ or a BPF file descriptor on BSD
+ <antrik> for a single network device? or all of them?
+ <antrik> AIUI the userspace BPF implementation in libpcap opens this
+ device, waits for packets, and if any arrive, decides depending on the
+ rules whether to pass them to the main program?
+ <braunr> antrik: that's it, but it's not the point
+ <braunr> antrik: the point is that, if programs need to include packet
+ sources in select/poll calls, they need file descriptors
+ <braunr> without a translator, i can't provide that
+ <braunr> so we either decide to stick with the libpcap patch only, and keep
+ this limitation, or we write a translator that enables this feature
+ <pinotree> braunr: are the two options exclusive?
+ <braunr> pinotree: unless we implement a complete bpf translator like i did
+ years ago, we'll need a patch in libpcap
+ <braunr> pinotree: the problem with my early translator implementation is
+ that it's buggy :(
+ <braunr> pinotree: and it's also slower, as packets are small enough to be
+ passed through raw copies
+ <antrik> braunr: I'm not sure what you mean when talking about "programs
+ including packet sources". programs only interact with packet sources
+ through libpcap, right?
+ <antrik> braunr: or are you saying that programs somehow include file
+ descriptors for packet sources (how do they obtain them?) in their main
+ loop, and explicitly pass control to libpcap once something arrives on
+ the respecitive descriptors?
+ <braunr> antrik: that's the idea, yes
+ <antrik> braunr: what is the idea?
+ <braunr> 20:38 < antrik> braunr: or are you saying that programs somehow
+ include file descriptors for packet sources (how do they obtain them?) in
+ their main loop, and explicitly pass control to libpcap once something
+ arrives on the respecitive descriptors?
+ <antrik> braunr: you didn't answer my question though :-)
+ <antrik> braunr: how do programs obtain these FDs?
+ <braunr> antrik: using pcap_fileno() for example
+
+
+## IRC, freenode, #hurd, 2012-02-02
+
+ <antrik> braunr: oh right, you already mentioned that one...
+ <antrik> braunr: so you want some entity that exposes the device as
+ something more POSIXy, so it can be used in standard FS calls, unlike the
+ Mach devices used for pfinet
+ <antrik> this is probably a good sentiment in general... but I'm not in
+ favour of a special solution only for BPF. rather I'd take this as an
+ indication that we probably should expose network interfaces as something
+ file-like in general after all, and adapt pfinet, eth-multiplexer, and
+ DDE accordingly
+ <braunr> antrik: i agree
+ <braunr> antrik: eth-multiplexer would be the right place
+
+
+## IRC, freenode, #hurd, 2012-04-24
+
+ <gnu_srs> braunr: Is BPF fully supported by now? Can it be used for
+ isc-dhcp?
+ <braunr> gnu_srs: bpf isn't supported at all
+ <braunr> gnu_srs: instead of emulating it, i added a hurd-specific module
+ in libpcap
+ <braunr> if isc-dhcp can use libpcap, then fine
+ <braunr> (otherwise we could create a hurd-specific patch for dhcp that
+ uses the in-kernel bpf filter implementation)
+ <braunr> gnu_srs: can't it use a raw socket ?
+ <youpi> it can
+ <youpi> it's just that the shape of the patch to do so wasn't exactly how
+ they needed it
+ <youpi> so they have to rework it a bit
+ <youpi> and that takes time
+ <braunr> ok
+ <braunr> antrik: for now, we prefer encapsulating the system specific code
+ in libpcap, and let users of that library benefit from it
+ <braunr> instead of implementing the low level bpf interface, which
+ nonetheless has some system-specific variants ..
+
+
+## IRC, freenode, #hurd, 2012-08-03
+
+In context of the [[select]] issue.
+
+ <braunr> i understand now why my bpf translator was so buggy
+ <braunr> the condition_timedwait i wrote at the time was .. incomplete :)
+
+
+## IRC, freenode, #hurd, 2014-02-04
+
+ <teythoon> btw, why is there a bpf filter in gnumach ?
+ <teythoon> braunr: didn't you put it there ?
+ <braunr> teythoon: ah yes i did
+ <braunr> teythoon: i completed the work of a friend
+ <braunr> teythoon: the original filters in mach were netf filters
+ <braunr> teythoon: we added bpf so that libpcap could directly upload them
+ to the kernel
+ <braunr> in order to apply filters as close as possible to the packet
+ source and save copies
+ <teythoon> so they were used with the in-kernel network drivers ?
+ <braunr> only by experimental code and pfinet which sets a
+ receive-all-inet4/6 filter
+ <braunr> i also have a pcap-hurd.c file for libpcap but integration is a
+ bit tricky because of netdde
+ <braunr> maybe i could work on it again some day
+ <braunr> it should be easy to get into the debian package at least
+ <teythoon> so they can still be used with a netdde-based driver ?
+ <braunr> i'm not sure
+ <braunr> the pcap-hurd.c file i wrote uses the libpcap bpf filter
+ <teythoon> oh, ok, i misinterpreted what you said wrt netdde
+ <braunr> the problem caused by netdde is about where to get packets from,
+ but devnode should take care of that
+ <teythoon> did you mean that the integration is tricky b/c when netdde is
+ used, a different approach is necessary and that would have to be
+ detected at runtime ?
+ <braunr> something like that
+ <teythoon> right
+ <braunr> i didn't want to detect anything
+ <teythoon> right
+ <braunr> i was waiting for things to settle but netdde is still debian only
+ <braunr> but that's ok, this oculd be a debian only patch for now
+ <teythoon> so is eth-filter the netdde equivalent or am i getting a wrong
+ picture here ?
+ <braunr> i don't know
+ <teythoon> it seems to implement bpf filters as well
+ <braunr> it could very well be
+ <braunr> whatever the driver, pfinet must be able to install a filter
+ <braunr> even if it's almost a catch-all
+ <teythoon> i guess it could start a eth-filter and use this, why not
+ <braunr> sure
+
+
+### IRC, freenode, #hurd, 2014-02-06
+
+ <antrik> teythoon: the BPF filter in Mach can also be used by
+ eth-multiplexer or eth-filter when running on in-kernel network
+ drivers... in fact the implementation was finished by the guy who created
+ eth-multiplexer; it was not fully working before
+ <antrik> it's not useful at all when using netdde I believe
+ <antrik> teythoon: IIRC eth-filted both relies on BPF being implemented by
+ the layer below it (whatever it is) to do the actual filtering, as well
+ as implements BPF itself so any layer on top of it can in turn use BPF
+ <antrik> netdde should provide BPF filters too I'd say... but don't
+ remember for sure
diff --git a/open_issues/bsd_compatibility.mdwn b/open_issues/bsd_compatibility.mdwn
new file mode 100644
index 00000000..5c916908
--- /dev/null
+++ b/open_issues/bsd_compatibility.mdwn
@@ -0,0 +1,34 @@
+[[!meta copyright="Copyright © 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_documentation]]
+
+IRC, freenode, #hurd, 2011-10-12:
+
+ <pinotree> hm, why our sys/param.h #define's BSD?
+ <braunr> pinotree: because we're evil
+ <pinotree> is that correct?
+ <pinotree> (the define, not the evilness)
+ <braunr> pinotree: i think it's because the Hurd is closer to the BSD
+ interfaces, probably because of Mach (which is itself derived from
+ BSD4.2)
+ <pinotree> braunr: but mach being bsd-ish won't make the userland (glibc)
+ interfaces bsd-ish, will it?
+ <braunr> pinotree: no
+ <pinotree> braunr: so...? :)
+ <braunr> pinotree: i guesse there are bsdisms in the glibc hurd specific
+ code, possibly because of mach
+ <braunr> or they used to be bsdisms, before being standardized
+ <braunr> e.g. mmap
+ <pinotree> braunr: hrmm...
+ <antrik> braunr: the BSDisms are there on purpose... Hurd was originally
+ even meant to be binary-compatible with BSD
+ <antrik> nothing to do with Mach really
+ <braunr> antrik: ok
diff --git a/open_issues/cannot_create__dev_null__interrupted_system_call.mdwn b/open_issues/cannot_create__dev_null__interrupted_system_call.mdwn
new file mode 100644
index 00000000..b0f14a17
--- /dev/null
+++ b/open_issues/cannot_create__dev_null__interrupted_system_call.mdwn
@@ -0,0 +1,193 @@
+[[!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]]."]]"""]]
+
+[[!tag open_issue_hurd]]
+
+
+# IRC, freenode, #hurd, 2013-12-05
+
+ <teythoon> Creating device nodes: fd fdX std vcs hdX hdXsY hdXs1Y sdX sdXsY
+ sdXs1Y cdX netdde ethX loopX ttyX ptyp ptyq/sbin/MAKEDEV: 75:
+ /sbin/MAKEDEV: cannot create /dev/null: Interrupted system call
+ <teythoon> that's new
+ <braunr> teythoon: ouch
+ <teythoon> braunr: everything works fine though
+ <braunr> teythoon: that part isn't too surprising
+ <teythoon> y?
+ <braunr> teythoon: /dev/null already existed, didn't it ?
+ <teythoon> braunr: sure, yes
+
+
+## IRC, freenode, #hurd, 2013-12-19
+
+ <braunr> hm
+ <braunr> i'm seeing those /sbin/MAKEDEV: cannot create /dev/null:
+ Interrupted system call messages too
+
+
+## IRC, freenode, #hurd, 2013-12-20
+
+ <teythoon> braunr: interesting, I've seen some of those as well
+
+
+## IRC, freenode, #hurd, 2014-01-26
+
+ <gg0> cannot create /dev/null: Interrupted system call
+ <gg0>
+ http://gnashdev.org:8010/builders/z-sid-hurd-i386/builds/26/steps/system_upgrade/logs/stdio
+
+
+## IRC, freenode, #hurd, 2014-01-27
+
+ <anatoly> gg0: I had same /dev/null error after upgrading my old image
+ (more than 6 months old) a week ago. But I got such message only on boot
+ and it didn't autostart hurd console.
+ <anatoly> Tried to upgrade current qemu image (from topic) to reproduce it
+ but it works OK after upgrade
+ <gg0> i can reproduce it with # apt-get install --reinstall python2.7 dbus
+ # for instance
+ <gg0> http://paste.debian.net/plain/78566/
+ <teythoon> gg0: i've seen those as well, but i cannot reliably reproduce it
+ to track it down
+ <teythoon> i believe it's benign though
+ <gg0> in shell scripts if -e is set, it aborts on failures like those
+ <teythoon> uh, it does? :/
+ <gg0> so if this happens in prerm/postinst scripts, package is not properly
+ installed/removed/configured and it fails
+ <gg0> redirecting stdout and strerr to /dev/null shouldn't be so
+ problematic, anything wrong in my setup?
+ <gg0> can you reproduce it?
+ <teythoon> not reliably
+ <teythoon> gg0: but i do not believe that anything is wrong with your
+ machine
+ <gg0> any way to debug it?
+ <teythoon> having a minimal test case that triggers this reliably would be
+ great
+ <teythoon> but i fear it might be a race
+
+
+## IRC, freenode, #hurd, 2014-01-28
+
+ <teythoon> have you seen the /dev/null issue ?
+ <braunr> yes
+ <teythoon> what do you make of it ?
+ <braunr> no idea
+ <teythoon> i believe it is related to the inlining work i've done
+ <braunr> just like the bogus deallocation at boot, it needs debugging :)
+ <braunr> hm i don't think so
+ <teythoon> no ?
+ <braunr> i think we saw it even before your started working on the hurd ;p
+ <teythoon> i've never seen it before my recent patches
+ <teythoon> maybe i made it worse
+ <braunr> not worse, just exposed more
+ <teythoon> right
+
+
+## IRC, freenode, #hurd, 2014-01-29
+
+ <gg0> cannot reproduce "cannot create /dev/null: Interrupted system call"
+ on a faster VM
+ <gg0> might depend on that?
+
+
+## IRC, OFTC, #debian-hurd, 2014-02-02
+
+ <pere> but now saw a strange message at the end of the boot:
+ /etc/init.dhurd-console: 55: /etc/init.d/hurd-console: cannot create
+ /dev/null: Interrupted system call
+ <gg0> oh well known on a slow VM (even old qemu/kvm btw), i can't reproduce
+ it on a faster/more recent one
+ <gg0> slow VM = gnash buildbot slave
+ http://gnashdev.org:8010/builders/z-sid-hurd-i386/builds/26/steps/system_upgrade/logs/stdio
+ <gg0> especially bad on system upgrade because it doesn't finish to run
+ prerm/postinst scripts :/
+
+
+## IRC, freenode, #hurd, 2014-02-05
+
+ <gg0> Creating device nodes: fd fdX std vcs hdX hdXsY/sbin/MAKEDEV: 75:
+ /sbin/MAKEDEV: cannot create /dev/null: Interrupted system call hdXs1Y
+ sdX sdXsY sdXs1Y cdX netdde ethX loopX ttyX ptyp ptyq lprX comX random
+ urandom kbd mouse shm.
+
+
+## IRC, freenode, #hurd, 2014-02-11
+
+ <gg0> typical dist-upgrade http://paste.debian.net/plain/81346/
+ <gg0> many fewer cannot create /dev/null: Interrupted system call
+ <gg0> on a faster machine
+ <teythoon> gg0: wow, so many interrupted system call messages
+ <teythoon> i don't get as many, but makedev produces a few every time i run
+ it as well
+
+
+## IRC, OFTC, #debian-hurd, 2014-02-16
+
+ <pere> anyone here got any idea why upgrading initscripts fail on the hurd
+ gnash autobuilder, as reported on <URL:
+ http://gnashdev.org:8010/builders/z-sid-hurd-i386/builds/28/steps/system_upgrade/logs/stdio
+ >?
+ <gg0> pere: cannot create /dev/null: Interrupted system call
+ <pere> gg0: I noticed the message, but fail to understand how this could
+ happen.
+ <gg0> 13:16 < gg0> oh well known on a slow VM (even old qemu/kvm btw), i
+ can't reproduce it on a faster/more recent one
+ <gg0> 13:17 < gg0> slow VM = gnash buildbot slave
+ http://gnashdev.org:8010/builders/z-sid-hurd-i386/builds/26/steps/system_upgrade/logs/stdio
+ <gg0> 13:18 < gg0> especially bad on system upgrade because it doesn't
+ finish to run prerm/postinst scripts :/
+ <gg0> i remember teythoon talking about something racy
+ <teythoon> gg0: the /dev/null issue is known for a long time
+ <teythoon> gg0: some of the recent work (i believe mine) has made the
+ problem more apparent
+ <teythoon> gg0: that's what braunr told me
+ <gg0> i see. it would be really nice fixing it. really annoying. i
+ workaround it by moving null away and moving it back under /dev before
+ halting/rebooting
+
+
+## IRC, freenode, #hurd, 2014-02-17
+
+ <tschwinge> Earlier today, I upgraded my Debian GNU/Hurd installation from
+ several months ago, and I'm now seeing bogus things as follows; is that a
+ known issue?
+ <tschwinge> checking for i686-unknown-gnu0.5-ar... ar
+ <tschwinge> configure: updating cache ./config.cache
+ <tschwinge> configure: creating ./config.status
+ <tschwinge> +./config.status: 299: ./config.status: cannot create
+ /dev/null: Interrupted system call
+ <tschwinge> config.status: creating Makefile
+ <tschwinge> (The plus is from a build log diff.)
+ <azeem> 13:36 < gg0> pere: cannot create /dev/null: Interrupted system call
+ <azeem> 20:10 < teythoon> gg0: the /dev/null issue is known for a long time
+ <tschwinge> Anyone working on resolving this? I't causing build issues:
+ <tschwinge> checking for i686-unknown-gnu0.5-ranlib... (cached) ranlib
+ <tschwinge> checking command to parse nm output from gcc-4.8
+ object... [...]/opcodes/configure: 6760: ./configure.lineno: cannot
+ create /dev/null: Interrupted system call
+ <tschwinge> failed
+ <tschwinge> checking for dlfcn.h... yes
+ <tschwinge> Anyway, will go researching IRC logs.
+ <azeem> tschwinge: (that one was from #debian-hurd)
+ <azeem> I assume teythoon and/or braunr can comment once he's back
+ <azeem> they're*
+ <braunr> tschwinge: we've been seing this more often lately but noone has
+ attempted to fix it yet
+ <braunr> tschwinge: if you have a reliable way to reproduce that /dev/null:
+ Interrupted system call error, please let us know
+
+
+## IRC, freenode, #hurd, 2014-02-23
+
+ <gg0> braunr: cool. i'd vote /dev/null one as next one in your todo
+ <gg0> still frequent on this slow vm
+ http://gnashdev.org:8010/builders/z-sid-hurd-i386/builds/30/steps/system_upgrade/logs/stdio
+ <gg0> especially during setup-translators -k
+ <braunr> yes
diff --git a/open_issues/chroot_difference_from_linux.mdwn b/open_issues/chroot_difference_from_linux.mdwn
new file mode 100644
index 00000000..f2009bd8
--- /dev/null
+++ b/open_issues/chroot_difference_from_linux.mdwn
@@ -0,0 +1,17 @@
+[[!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]]."]]"""]]
+
+\#hurd, freenode, 2010
+
+ <cfhammar> weird, even fd = open("/"), chroot("/tmp/chroot"), openat(fd, "/tmp/chroot/..) opens /tmp/chroot in linux
+ <pochu> cfhammar: isn't that expected?
+ <cfhammar> pochu: well, i didn't expect it :-)
+ <cfhammar> pochu: in hurd, /tmp gets opened, which i think is more natural
+ <pochu> cfhammar: oh right, didn't notice the ".." :-)
diff --git a/open_issues/clock_gettime.mdwn b/open_issues/clock_gettime.mdwn
new file mode 100644
index 00000000..407a104c
--- /dev/null
+++ b/open_issues/clock_gettime.mdwn
@@ -0,0 +1,348 @@
+[[!meta copyright="Copyright © 2011, 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]]."]]"""]]
+
+[[!meta title="clock_gettime"]]
+
+[[!tag open_issue_glibc open_issue_gnumach]]
+
+Missing `clock_gettime(CLOCK_MONOTONIC)` (e.g. for iceweasel)
+
+It could be a mere matter of extending the
+[[mapped-time_interface|microkernel/mach/gnumach/interface/device/time]]:
+add it to
+`mapped_time_value_t` in gnumach, handle it in `gnumach/kern/mach_clock.c`, and
+make `clock_gettime` use it.
+
+BTW, also make `gettimeofday()` use it, since it's way more efficient and some
+applications assume that it is.
+
+What about adding a nanosecond-precision clock, too? --[[tschwinge]]
+
+
+# IRC, freenode, #hurd, 2011-08-26
+
+ < pinotree> youpi: thing is: apparently i found a simple way to have a
+ monotonic clock as mmap-able device inside gnumach
+ < pinotree> currently, in kern/mach_clock.c there's a variable 'time',
+ which gets increased on clock interrupt, and optionally modified by
+ host_set_time
+ < pinotree> ()
+ < pinotree> if i add a new variable next to it, only increasing it on
+ interrupt but not modifying it at all otherwise, would that give me a
+ monotonic clock?
+ < pinotree> at least on sme basic tests i did, it seems it could work that
+ way
+ < youpi> yes, it should work
+ < braunr> sure
+ < youpi> and that's the way I was considering implementing it
+
+
+# IRC, freenode, #hurd, 2011-09-06
+
+ <pinotree> yeah, i had a draft of improved idea for also handling
+ nanoseconds
+ <tschwinge> pinotree: Ah, nice, I thought about nanoseconds as well.
+ <tschwinge> pinotree, youpi: This memory page is all-zero by default,
+ right?
+ <tschwinge> Can't we then say that its last int is a version code, and if
+ it is 0 (as it is now), we only have the normal mapped time field, if it
+ is 1, we also have the monotonic cliock and ns precision on address 8 and
+ 16 (or whatever)?
+ <tschwinge> In case that isn't your plan anyway.
+ <youpi> it's all-zero, yes
+ <tschwinge> Or, we say if a field is != 0 it is valid.
+ <youpi> making the last int a version code limits the size to one page
+ <youpi> I was thinking a field != 0 being valid is simpler
+ <youpi> but it's probably a problem too
+ <youpi> in that glibc usually caches whether interfaces are supported
+ <tschwinge> Wrap-around?
+ <youpi> for some clocks, it may be valid that the value is 0
+ <youpi> wrap-around is another issue too
+ <tschwinge> Well, then we can do the version-field thing, but put it right
+ after the current time field (address 8, I think)?
+ <youpi> yes
+ <youpi> it's a bit ugly, but it's hidden behind the structure
+ <tschwinge> It's not too bad, I think.
+ <youpi> yes
+ <tschwinge> And it will forever be a witness of the evolving of this
+ map_time interface. :-)
+
+
+# IRC, freenode, #hurd, 2013-02-11
+
+In context of [[select]].
+
+ <pinotree> braunr: would you send for review (and inclusion) your
+ time_data_t addition?
+ <pinotree> this way we could add nanosecs-based utime rpc (and then their
+ implementation in libc)
+ <braunr> pinotree: it's part of the hurd branch
+ <braunr> do you want it sent separately ?
+ <pinotree> yeah
+ <braunr> ok
+ <braunr> let me get it right first :)
+ <pinotree> sure :)
+
+
+## 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
+ <pinotree> uh nice
+ <pinotree> will need two small inline functions to convert time_data_t <->
+ timespec, but that's it
+ <braunr> hm right
+ <braunr> i could have thought about it
+ <braunr> but i'll leave it for another patch :p
+ <pinotree> oh sure, no hurry
+
+
+## IRC, freenode, #hurd, 2013-02-19
+
+ <youpi> braunr: about time_data_t, I get it's needed that it be an array
+ <youpi> so it can be passed by reference, not by value?
+ <braunr> by address, yes
+ <braunr> that's the difference between array and struct
+
+
+## IRC, freenode, #hurd, 2013-02-25
+
+ <youpi> braunr: why did you want to see time_data passed as pointer, not as
+ struct?
+ <braunr> to microoptimize
+ <braunr> the struct is 2 64-bit integers
+ <youpi> well, we already pass structs along in a few cases,
+ e.g. io_statbuf_t, rusage_t, etc.
+ <youpi> be it written t[0].sec or t->sec, it seems odd
+ <youpi> copying 2 64bit integers is not much compared to the potential for
+ bugs here
+ <braunr> bugs ?
+ <youpi> yes, as in trying to access t[1], passing a wrong pointer, etc.
+ <youpi> or the reader frowning on "why is this case different than the
+ others?"
+ <braunr> well, i'm already usually frowning when i see what mig does ..
+ <youpi> right
+ <youpi> on the plus side, it's only the client side, i.e. mostly glibc,
+ which sees the t[0]
+ <braunr> and the practice established by my patch is to convert to struct
+ timespec as soon as possible
+ <braunr> the direct use of this type is therefore limited
+ <youpi> could we define time_data_t as a struct time_data * instead of
+ struct time_data[1] ?
+ <youpi> (in the.h)
+ <youpi> that would make more sense to define a struct time_data, and pass a
+ pointer to it
+ <braunr> i'm not sure
+ <braunr> the mach server writing guide was very clear about array implying
+ a C array too
+ <braunr> and i remember having compilation problems before doing that
+ <braunr> but i don't remember their nature exactly
+ <youpi> I'm not sure to understand what you said about converting to struct
+ timespec
+ <youpi> what makes it not possible now?
+ <youpi> and what is the relation with being an array or a pointer?
+ <braunr> concerning struct timespec, what i mean is that the functions
+ called by the mig stub code directly convert time_data_t to a struct
+ timespec (which is the real type used throughout the hurd code)
+ <braunr> about the rest, i'm not sure, i'd have to try again
+ <braunr> mig just assumes it's an array
+ <youpi> and why not just using struct timespec?
+ <youpi> (for the mig type too)
+ <braunr> my brain can't correctly compute variable sized types in mig
+ definition files
+ <braunr> i wanted something that would remain correct for the 64-bit port
+
+[[64-bit_port]], [[mig_portable_rpc_declarations]].
+
+ <youpi> ah, you mean because tv_nsec is a long, which will not be the same
+ type?
+ <braunr> and tv_sec being a time_t (thus a long too)
+ <youpi> but we have the same issue e.g. for the rusage structure, don't we?
+ <braunr> yes
+ <youpi> so we'll have to fix things for that too anyway
+ <braunr> sure
+ <youpi> making a special case will not necessarily help
+ <braunr> but it doesn't mean new interfaces have to be buggy too
+ <youpi> well, using the proper type in the server itself is nicer
+ <youpi> instead of having to convert
+ <braunr> yes
+ <braunr> i'm not exactly sure where to declare struct timespec then
+ <braunr> should it be declared in hurd_types.h, and simply reused by the
+ libc headers ?
+ <youpi> ? AIUI, it's the converse, hurd_types.h uses the struct timespec
+ from libc headers, and defines timespec_t
+ <braunr> ok
+ <youpi> timespec_t being the internal type whose definition gets done right
+ for mig to do the right thing
+ <braunr> yes
+ <braunr> i see
+ <braunr> so, you'd like a struct of integer_t instead of an array of
+ signed64
+ <youpi> for our current 32bit userland yes
+ <braunr> do you want to make the changes yourself or should i add a new
+ branch ?
+ <youpi> and we'll make that a 64bit struct when we have a64bit userland
+
+
+# IRC, freenode, #hurd, 2013-04-06
+
+ <tschwinge> pinotree: You had once been working on adding nsec-procision
+ timestamps to GNU Mach's maptime interface (or what the name is). Is
+ that blocked on something or just waiting to be continued?
+ <pinotree> blocked on me needing to learn more the proper way to do
+ "atomic" update of the struct with time :)
+
+
+# IRC, freenode, #hurd, 2013-09-04
+
+ <teythoon> do we have CLOCK_MONOTONIC ?
+ <braunr> teythoon: i think we do but it's actually a simple offset from
+ CLOCK_REALTIME .. :)
+ <teythoon> ah never mind, I do hate this posix time interface anyways
+ <braunr> really ?
+ <braunr> i think librt is decent
+
+
+# Candidate for [[vDSO]] code?
+
+
+# IRC, freenode, #hurd, 2014-02-23
+
+ <desrt> GLib (gthread-posix.c): Unexpected error from C library during
+ 'pthread_condattr_setclock': Invalid argument. Aborting.
+ <desrt> uh oh...
+ <desrt> time to go digging in glibc i guess...
+ <braunr> what are you trying to run ?
+ <desrt> glib
+ <braunr> with what ?
+ <desrt> just running glib's test suite under jhbuild
+ <desrt> i maintain glib and i made some changes recently -- i wanted to
+ make sure they didn't break the hurd
+ <desrt> and it seems they have ;/
+ <braunr> well
+ <braunr> the hurd doesn't completely comply with posix 2008
+ <desrt> long story short: we've keyed our timed waits on condition
+ variables to the monotonic clock for a long time now, but we never tested
+ that it actually worked
+ <desrt> so i just added an assert -- and indeed it fails on hurd
+ <braunr> our glibc lies about supporting timers
+ <braunr> good thinking
+ <braunr> we don't support the monotonic clock
+ <desrt> clock_gettime(CLOCK_MONOTONIC) seems to work
+ <braunr> and you should know that, even if clock selection and timers are
+ available (which posix 2008 requires), it's still optional
+ <braunr> no, glibc lies
+ <desrt> !!
+ <braunr> our "support" is a mere hack shifting CLOCK_REALTIME
+ <desrt> it should at least lie consistently :)
+ <braunr> we need to implement CLOCK_MONOTONIC properly
+ <desrt> ya... that would be very nice indeed
+ <braunr> not that hard either
+ <desrt> i agree!
+ <braunr> we just have to do it right
+ <desrt> fwiw, i plan to keep this assert in glib
+ <braunr> yes, it's good
+ <desrt> is there anywhere i can file a bug to give you guys some advance
+ warning?
+ <braunr> i don't think it's needed
+ <braunr> we know the problem
+ <desrt> k -- consider yourself warned, then :)
+ <braunr> and it's been a bigger concern recently
+ <desrt> awesome. glad i don't have to do anything :)
+ <braunr> if it's not already done, i suggest you check for the
+ CLOCK_MONOTONIC option
+ <desrt> fwiw, i'm trying to get a regular debian/gnu/hurd build of
+ glib/gtk/etc setup
+ <braunr> regular ?
+ <desrt> ya... out of git master on a daily basis
+ <braunr> from sources ?
+ <braunr> oh nice
+ <desrt> we recently set this up for freebsd as well
+ <braunr> few maintainers take the pain :)
+ <desrt> our non-linux 'problem discovery' is a bit crap before now :/
+ <braunr> i guess that's pretty normal
+ <braunr> i don't consider it the responsibility of the maintainers to test
+ every possible platform
+ <desrt> glib is a bit unique -- portability is our business
+ <braunr> taking our patches into consideration is what we ask most
+ <braunr> right
+ <desrt> and the "please take the patches" thing is something we want to
+ stop doing
+ <braunr> why ?
+ <desrt> mostly because we often look at a patch that someone sent a few
+ years ago and say "do we even still need this?"
+ <desrt> and have no way to know
+ <braunr> uh
+ <desrt> you would not believe how many patches like this we've
+ accumulated...
+ <braunr> but if we send it now ? :)
+ <desrt> braunr: new policy is roughly this:
+ https://wiki.gnome.org/Projects/GLib/SupportedPlatforms
+ <desrt> ie: fixes for issues that are general portability improvements and
+ POSIX compliance are welcome...
+ <desrt> patches that introduce platform-specific #ifdef sections are
+ rejected unless we have a regular builder to test that code
+ <braunr> i see
+ <braunr> again, regarding portability, don't consider CLOCK_MONOTONIC to be
+ readily available, check for it
+ <braunr> an #error would be enough but it has to be checked
+ <desrt> it basically comes down to: we don't want to have code in our
+ version control that we have no possible way of testing
+ <braunr> yes
+ <desrt> braunr: we do check for it
+ <braunr> ok
+ <desrt> we assert() if clock_gettime(CLOCK_MONOTONIC) fails
+ <braunr> no i mean
+ <desrt> as POSIX said it should if CLOCK_MONOTONIC is not supported
+ <desrt> if you lie to us.... well, not much we can do
+ <braunr> POSIX_MONOTONIC_CLOCK
+ <braunr> _POSIX_MONOTONIC_CLOCK
+ <desrt> this is actually defined to 0 on most platforms...
+ <desrt> which does not mean that it's unsupported -- it means that the
+ runtime must be ready to deal with it not actually existing at runtime
+ <braunr> really ?
+ <desrt> yes
+ <desrt> we used to rely on this and got a bug that we were doing it wrong
+ :)
+ <desrt> and indeed, even on linux, both with glibc and uclibc:
+ <desrt> /usr/include/bits/posix_opt.h:#define _POSIX_MONOTONIC_CLOCK
+ 0
+ <desrt> /usr/include/uClibc/bits/posix_opt.h:#define _POSIX_MONOTONIC_CLOCK
+ 0
+ <braunr> ok it's described in 2.1.6 Options
+ <braunr> so your check is appropriate
+ <desrt> so does clock_gettime(MONOTONIC) on debian/hurd get me realtime?
+ <braunr> either that, or a value shifted from it
+ <desrt> if so, i'll just hack out the condattr_setclock() check and proceed
+ trying to build past glib...
+ * desrt checks
+ <desrt> as it is, even the build of glib fails since we use some tools
+ linked against ourselves during the build process...
+ <desrt> 1393124084790000 1393124084790000
+ <desrt> those look the same....
+ <braunr> heh
+ <desrt> i also notice that your clocks are not very high precision :)
+ <braunr> that's right
+ <desrt> HZ = 100, i guess
+ <braunr> yes
+ <desrt> fair enough
+ <desrt> our mainloop doesn't support better-than-millisecond accuracy yet
+ anyway :)
+ <desrt> (although it will soon...)
+ <braunr> nice
+
+
+## IRC, freenode, #hurd, 2014-03-05
+
+ <desrt> braunr: bit of a warning: i released the glib that depends on
+ working pthread_condattr_setclock(..._MONOTONIC) and pochu said that it
+ will be landing in debian within the next days
+ <braunr> desrt: ok
diff --git a/open_issues/code_analysis.mdwn b/open_issues/code_analysis.mdwn
new file mode 100644
index 00000000..df434b76
--- /dev/null
+++ b/open_issues/code_analysis.mdwn
@@ -0,0 +1,277 @@
+[[!meta copyright="Copyright © 2010, 2011, 2012, 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]]."]]"""]]
+
+In the topic of *code analysis* or *program analysis* ([[!wikipedia
+Program_analysis_(computer_science) desc="Wikipedia article"]]), there is
+static code analysis ([[!wikipedia Static_code_analysis desc="Wikipedia
+article"]]) and dynamic program analysis ([[!wikipedia Dynamic_program_analysis
+desc="Wikipedia article"]]). This topic overlaps with [[performance
+analysis|performance]], [[formal_verification]], as well as general
+[[debugging]].
+
+[[!toc]]
+
+
+# Bounty
+
+There is a [[!FF_project 276]][[!tag bounty]] on some of these tasks.
+
+
+# Static
+
+ * [[GCC]]'s warnings. Yes, really.
+
+ * GCC plugins can be used for additional semantic analysis. For example,
+ <http://lwn.net/Articles/457543/>, and search for *kernel context* in
+ the comments.
+
+ * Have GCC make use of [[RPC]]/[[microkernel/mach/MIG]] *in*/*out*
+ specifiers, and have it emit useful warnings in case these are pointing
+ to uninitialized data (for *in* only).
+
+ * [[!wikipedia List_of_tools_for_static_code_analysis]]
+
+ * [Engineering zero-defect software](http://esr.ibiblio.org/?p=4340), Eric
+ S. Raymond, 2012-05-13
+
+ * [Static Source Code Analysis Tools for C](http://spinroot.com/static/)
+
+ * [Cppcheck](http://sourceforge.net/apps/mediawiki/cppcheck/)
+
+ For example, [Debian's hurd_20110319-2
+ package](http://qa.debian.org/daca/cppcheck/sid/hurd_20110319-2.html)
+ (Samuel Thibault, 2011-08-05: *I had a look at those, some are spurious;
+ the realloc issues are for real*).
+
+ * Coccinelle
+
+ * <http://lwn.net/Articles/315686/>
+
+ * <http://www.google.com/search?q=coccinelle+analysis>
+
+ Has already been used for finding and fixing [[!message-id desc="double
+ mutex unlocking issues"
+ "1355701890-29227-1-git-send-email-tipecaml@gmail.com"]].
+
+ * [clang](http://www.google.com/search?q=clang+analysis)
+
+ * <http://darnassus.sceen.net/~teythoon/qa/gnumach/scan-build>
+
+ * <http://darnassus.sceen.net/~teythoon/qa/hurd/scan-build>
+
+ * [Linux' sparse](https://sparse.wiki.kernel.org/)
+
+ * <http://klee.llvm.org/>
+
+ * <http://blog.llvm.org/2010/04/whats-wrong-with-this-code.html>
+
+ * [Smatch](http://smatch.sourceforge.net/)
+
+ * [Parfait](http://labs.oracle.com/projects/parfait/)
+
+ * <http://lwn.net/Articles/344003/>
+
+ * [Saturn](http://saturn.stanford.edu/)
+
+ * [Flawfinder](http://www.dwheeler.com/flawfinder/)
+
+ * [sixgill](http://sixgill.org/)
+
+ * [s-spider](http://code.google.com/p/s-spider/)
+
+ * [CIL (C Intermediate Language)](http://kerneis.github.com/cil/)
+
+ * [Frama-C](http://frama-c.com/)
+
+ <teythoon> btw, I've been looking at http://frama-c.com/ lately
+ <teythoon> it's a theorem prover for c/c++
+ <braunr> oh nice
+ <teythoon> I think it's most impressive, it works on the hurd (aptitude
+ install frama-c o_O)
+ <teythoon> *and it works
+ <braunr> "Simple things should be simple,
+ <braunr> complex things should be possible."
+ <braunr> :)
+ <braunr> looks great
+ <teythoon> even the gui is awesome, allows one to browse source code in
+ a very impressive way
+ <braunr> clear separation between value changes, dependencies, side
+ effects
+ <braunr> we could have plugins for stuff like ports
+ <braunr> handles concurrency oO
+ <nalaginrut> so you want to use Frame-C to analyze the whole Hurd code
+ base?
+ <teythoon> nalaginrut: well, frama-c looks "able" to assist in
+ analyzing the Hurd, yes
+ <teythoon> nalaginrut: but theorem proving is a manual process, one
+ needs to guide the prover
+ <teythoon> nalaginrut: b/c some stuff is not decideable
+ <nalaginrut> I ask this because I can imagine how to analyze Linux
+ since all the code is in a directory. But Hurd's codes are
+ distributed to many other projects
+ <braunr> that's not a problem
+ <braunr> each server can be analyzed separately
+ <teythoon> braunr: also, each "entry point"
+ <nalaginrut> alright, but sounds a big work
+ <teythoon> it is
+ <braunr> otherwise, formal verification would be widespread :)
+ <teythoon> that, and most tools are horrible to use, frama-c is really
+ an exception in this regard
+
+ * [Coverity](http://www.coverity.com/) (nonfree)
+
+ * <https://scan.coverity.com/projects/1307> If you want access, speak up in #hurd or on the mailing list.
+
+ * IRC, OFTC, #debian-hurd, 2014-02-03
+
+ <pere> btw, did you consider adding hurd and mach to <URL:
+ https://scan.coverity.com/ > to detect bugs automatically?
+ <pere> I found lots of bugs in gnash, ipmitool and sysvinit when I
+ started scanning those projects. :)
+ <teythoon> i did some static analysis work, i haven't used coverty
+ but free tools for that
+ <teythoon> i think thomas wanted to look into coverty though
+ <pere> quite easy to set up, but you need to download and run a
+ non-free tarball on the build host.
+ <teythoon> does that tar ball contains binary code ?
+ <teythoon> that'd be a show stopper for the hurd of course
+ <pere> did not investigate. I just put it in a contained virtual
+ machine.
+ <pere> did not want it on my laptop. :)
+ <pere> prefer free software here. :)
+ <pere> but I did not have to "accept license", at least. :)
+
+ * IRC, OFTC, #debian-hurd, 2014-02-05
+
+ <pere> ah, cool. <URL: https://scan.coverity.com/projects/1307 >
+ is now in place. :)
+
+ [[microkernel/mach/gnumach/projects/clean_up_the_code]],
+ *Code_Analysis, Coverity*.
+
+ * [Splint](http://www.splint.org/)
+
+ * IRC, freenode, #hurd, 2011-12-04
+
+ <mcsim> has anyone used splint on hurd?
+ <mcsim> this is tool for statically checking C programs
+ <mcsim> seems I made it work
+
+
+## Hurd-specific Applications
+
+ * [[Port Sequence Numbers|microkernel/mach/ipc/sequence_numbering]]. If
+ these are used, care must be taken to update them reliably, [[!message-id
+ "1123688017.3905.22.camel@buko.sinrega.org"]]. This could be checked by a
+ static analysis tool.
+
+ * [[glibc]]'s [[glibc/critical_section]]s.
+
+
+# Dynamic
+
+ * [[community/gsoc/project_ideas/Valgrind]]
+
+ * glibc's `libmcheck`
+
+ * Used by GDB, for example.
+
+ * Is not thread-safe, [[!sourceware_PR 6547]], [[!sourceware_PR 9939]],
+ [[!sourceware_PR 12751]], [[!stackoverflow_question 314931]].
+
+ * <http://en.wikipedia.org/wiki/Electric_Fence>
+
+ * <http://sourceforge.net/projects/duma/>
+
+ * <http://wiki.debian.org/Hardening>
+
+ * <https://wiki.ubuntu.com/CompilerFlags>
+
+ * `MALLOC_CHECK_`/`MALLOC_PERTURB_`
+
+ * IRC, freenode, #glibc, 2011-09-28
+
+ <vsrinivas> two things you can do -- there is an environment
+ variable (DEBUG_MALLOC_ iirc?) that can be set to 2 to make
+ ptmalloc (glibc's allocator) more forceful and verbose wrt error
+ checking
+ <vsrinivas> another is to grab a copy of Tor's source tree and copy
+ out OpenBSD's allocator (its a clearly-identifyable file in the
+ tree); LD_PRELOAD it or link it into your app, it is even more
+ aggressive about detecting memory misuse.
+ <vsrinivas> third, Red hat has a gdb python plugin that can
+ instrument glibc's heap structure. its kinda handy, might help?
+ <vsrinivas> MALLOC_CHECK_ was the envvar you want, sorry.
+
+ * [`MALLOC_PERTURB_`](http://udrepper.livejournal.com/11429.html)
+
+ * <http://git.fedorahosted.org/cgit/initscripts.git/diff/?id=deb0df0124fbe9b645755a0a44c7cb8044f24719>
+
+ * In context of [[!message-id
+ "1341350006-2499-1-git-send-email-rbraun@sceen.net"]]/the `alloca` issue
+ mentioned in [[gnumach_page_cache_policy]]:
+
+ IRC, freenode, #hurd, 2012-07-08:
+
+ <youpi> braunr: there's actually already an ifdef REDZONE in libthreads
+
+ It's `RED_ZONE`.
+
+ <youpi> except it seems clumsy :)
+ <youpi> ah, no, the libthreads code properly sets the guard, just for
+ grow-up stacks
+
+ * GCC, LLVM/clang: [[Address Sanitizer (asan), Memory Sanitizer (msan),
+ Thread Sanitizer (tasn), Undefined Behavor Sanitizer (ubsan), ...|_san]]
+
+ * [GCC plugins](http://gcc.gnu.org/wiki/plugins)
+
+ * [CTraps](https://github.com/blucia0a/CTraps-gcc)
+
+ > CTraps is a gcc plugin and runtime library that inserts calls to runtime
+ > library functions just before shared memory accesses in parallel/concurrent
+ > code.
+ >
+ > The purpose of this plugin is to expose information about when and how threads
+ > communicate with one another to programmers for the purpose of debugging and
+ > performance tuning. The overhead of the instrumentation and runtime code is
+ > very low -- often low enough for always-on use in production code. In a series
+ > of initial experiments the overhead was 0-10% in many important cases.
+
+ * Input fuzzing
+
+ Not a new topic; has been used (and papers published?) for early [[UNIX]]
+ tools. What about some [[RPC]] fuzzing?
+
+ * <http://caca.zoy.org/wiki/zzuf>
+
+ * <http://www.ece.cmu.edu/~koopman/ballista/>
+
+ * [Jones: system call abuse](http://lwn.net/Articles/414273/), Dave
+ Jones, 2010.
+
+ * [Trinity: A Linux kernel fuzz tester (and then
+ some)](http://www.socallinuxexpo.org/scale11x/presentations/trinity-linux-kernel-fuzz-tester-and-then-some),
+ Dave Jones, The Eleventh Annual Southern California Linux Expo, 2013.
+
+ * Mayhem, *an automatic bug finding system*
+
+ IRC, freenode, #hurd, 2013-06-29:
+
+ <teythoon> started reading the mayhem paper referenced here
+ http://lists.debian.org/debian-devel/2013/06/msg00720.html
+ <teythoon> that's nice work, they are doing symbolic execution of x86
+ binary code, that's effectively model checking with some specialized
+ formulas
+ <teythoon> (too bad the mayhem code isn't available, damn those
+ academic people keeping the good stuff to themselvs...)
+ <teythoon> (and I really think that's bad practice, how should anyone
+ reproduce their results? that's not how science works imho...)
diff --git a/open_issues/code_analysis/discussion.mdwn b/open_issues/code_analysis/discussion.mdwn
new file mode 100644
index 00000000..45126b91
--- /dev/null
+++ b/open_issues/code_analysis/discussion.mdwn
@@ -0,0 +1,245 @@
+[[!meta copyright="Copyright © 2011, 2012, 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]]."]]"""]]
+
+[[!tag open_issue_documentation]]
+
+[[!toc]]
+
+
+# IRC, freenode, #hurd, 2011-12-04
+
+ <mcsim> defpager uses it's own dynamic memory allocator, which uses
+ vm_allocate/vm_deallocate as backing store? Am I able to use duma in such
+ case?
+ <braunr> you will have to adapt it
+ <braunr> but it's already designed to handle custom allocators
+ <braunr> iirc
+ <braunr> btw, are there special flags for that memory which the pager
+ allocates ?
+ <braunr> e.g. to use wired memory ?
+ <mcsim> yes, wired memory
+ <braunr> you'll have to change that in duma then
+ <braunr> but apart from such details, it should be straightforward
+
+ <antrik> braunr: I have no idea about duma; but if you think it's a useful
+ tool, please add it to open_issues/code_analysis.mdwn
+ <antrik> (I guess we should have a "proper" page listing useful debugging
+ tools...)
+
+
+## IRC, freenode, #hurd, 2012-09-03
+
+ <mcsim> hello. Has anyone tried some memory debugging tools like duma or
+ dmalloc with hurd?
+ <braunr> mcsim: yes, but i couldn't
+ <braunr> i tried duma, and it crashes, probably because of cthreads :)
+
+
+# Static Analysis
+
+## IRC, freenode, #hurd, 2012-09-08
+
+ <mcsim> hello. What static analyzer would you suggest (probably you have
+ tried it for hurd already)?
+ <braunr> mcsim: if you find some good free static analyzer, let me know :)
+ <pinotree> a simple one is cppcheck
+ <mcsim> braunr: I'm choosing now between splint and adlint
+
+
+## IRC, freenode, #hurd, 2013-10-17
+
+ <teythoon> whoa, llvm kinda works, enough to make scan-build work :)
+ <braunr> teythoon: what is scan-build ?
+ <teythoon> braunr: clangs static analyzer
+ <braunr> ok
+ <teythoon> I'm doing a full build of the hurd using it, I will post the
+ report once it is finished
+ <teythoon> this will help spot many problems
+ <teythoon> well, here are the scan-build reports I got so far:
+ https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/
+ <teythoon> I noticed it finds problems in mig generated code, so there are
+ probably lot's of duplictaes for those kind of problems
+ <pinotree> what's a... better one to look at?
+ <teythoon> it's also good at spotting error handling errors, and can spot
+ leaks sometimes
+ <teythoon> hm
+ <teythoon>
+ https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/report-yVBHO1.html
+ <braunr> that's minor, the device always exist
+ <braunr> but that's still ugly
+ <teythoon>
+ https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/report-MtgWSa.html
+ <teythoon>
+ https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/report-QdsZIm.html
+ <teythoon> this could be important:
+ https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/report-PDMEbk.html
+ <teythoon> this is the issue it finds in mig generated server stubs:
+ https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/report-iU3soc.html
+ <braunr> this one is #if TypeCheck1
+ <braunr> the libports one looks weird indeed
+ <teythoon> but TypeCheck is 1 (the tooltip shows macro expansion)
+ <teythoon> it is defined in line 23
+ <braunr> oh
+ <teythoon> hmmm... clang does not support nested functions, that will limit
+ its usefulness for us :/
+ <braunr> yes
+ <braunr> one more reason not to use them
+
+
+### IRC, freenode, #hurd, 2013-10-18
+
+ <teythoon> more complete, now with index:
+ https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build-2/
+
+
+### IRC, freenode, #hurd, 2013-11-04
+
+ <teythoon> btw, why does the nested functions stuff needs the executable
+ stack? for trampolines?
+ <braunr> yes
+ <teythoon> I didn't even realize that, that's one more reason to avoid them
+ indeed
+
+ <teythoon> braunr: kern/slab.c (1471): vm_size_t info_size = info_size;
+ <braunr> yes ?
+ <teythoon> braunr: what's up with that?
+ <braunr> that's one way to silence gcc warnings about uninitialized
+ variables
+ <braunr> this warning can easily result in false positives when gcc is
+ unable to determine dependencies
+ <braunr> e.g. if (flag & FLAG_CREATE) myvar = create(); ...; ... if (flag &
+ FLAG_CREATE) use(myvar)
+ <teythoon> well, ok, that's a shortcomming of gcc
+ <teythoon> braunr: your way of silencing that in gcc still shows up in
+ scan-build and most likely any more advanced analysis tool
+ <teythoon> as it should of course, but it is noisy
+ <braunr> teythoon: there is a gcc attribute for that
+ <braunr> __attribute__((unused))
+ <braunr> analysis tools might know that better
+ <teythoon> braunr: could you have a quick look at
+ http://darnassus.sceen.net/~teythoon/qa/gnumach/scan-build/2013-11-04/report-mXqstT.html#EndPath
+ ?
+ <braunr> nice
+ <braunr> anything else on the rbtree code ?
+ <teythoon> well
+ <teythoon>
+ http://darnassus.sceen.net/~teythoon/qa/gnumach/scan-build/2013-11-04/report-LyiOO1.html#EndPath
+ <teythoon> but this is of length 18, so it might be far-fetched
+ <braunr> ??
+ <teythoon> the length of the chain of argumentation
+ <braunr> i don't understand that issue
+ <braunr> isn't 18 the analysis step ?
+ <teythoon> well, the greater the length, the more assumption the tool
+ makes, the more likely it is that it just does not "get" some invariant
+ <braunr> probably yes
+ <braunr> the code can segfault if input parameters are invalid
+ <braunr> that's expected
+ <teythoon> right, looks like this only happens if the tree is invalid
+ <teythoon> if in line 349 brother->children[right] is NULL
+ <teythoon> this is a very good target for verification using frama-c
+ <braunr> :)
+ <teythoon> the code already has many assertions that will be picked up by
+ it automatically
+ <teythoon> so what about the dead store, is it a bug or is it harmless ?
+ <braunr> harmless probably
+ <braunr> certainly
+ <braunr> a simple overlook when polishing
+
+
+### IRC, freenode, #hurd, 2014-01-16
+
+ <mcsim> braunr: hi. Once, when I wrote a lot if inline gcc functions in
+ kernel you said me not to use them. And one of the arguments was that you
+ want to know which binary will be produced. Do you remember that?
+ <braunr> not exactly
+ <braunr> it seems likely that i advice not to use many inline functions
+ <braunr> but i don't see myself stating such a reason
+ <mcsim> braunr: ok
+ <mcsim> so, what do you think about using some high level primitives in
+ kernel
+ <mcsim> like inline-functions
+ <mcsim> ?
+ <braunr> "high level primitives" ?
+ <braunr> you mean switching big and important functions into inline code ?
+ <mcsim> braunr: something that is hard to translate in assembly directly
+ <mcsim> braunr: I mean in general
+ <braunr> i think it's bad habit
+ <mcsim> braunr: why?
+ <braunr> don't inline anything at first, then profile, then inline if
+ function calls really are a bottleneck
+ <mcsim> my argument would be that it makes code more readable
+ <braunr> https://www.kernel.org/doc/Documentation/CodingStyle <= see the
+ "inline disease"
+ <braunr> uh
+ <braunr> more readable ?
+ <braunr> the only difference is an inline keyword
+ <mcsim> sorry
+ <mcsim> i confused with functions that you declare inside functions
+ <mcsim> nested
+ <mcsim> forgot the word
+ <mcsim> sorry
+ <braunr> ah nested
+ <braunr> my main argument against nested functions is that they're not
+ standard and hard to support for non-gcc tools
+ <braunr> another argument was that it required an executable stack but
+ there is apparently a way to reliably make nested functions without this
+ requirement
+ <braunr> so, at the language level, they bring nice closures
+ <braunr> the problem for me is at the machine level
+ <braunr> i don't know them well so i'm unable to predict the kind of code
+ they generate
+ <braunr> but i guess anyone who would take the time to study their
+ internals would be able to do that
+ <mcsim> and why this last argument is important?
+ <braunr> because machine code runs on machines
+ <braunr> one shouldn't ignore the end result ..
+ <braunr> if you don't know the implications of what you're doing precisely,
+ you loose control over the result
+ <braunr> if you can trust the tool, fine
+ <kilobug> mcsim: in general, when you use something you don't really
+ understand how it works internally, you've a much higher risk of making
+ bugs or inefficient code because you just didn't realize it couldn't work
+ or would be inefficient
+ <braunr> but in the case of a kernel, it often happens that you can't, or
+ at least not in a straightforward way
+ <braunr> s/loose/lose/
+ <mcsim> kilobug: and that's why for kernel programming you try to use the
+ most straightforward primitives as possible?
+ <braunr> no
+ <kilobug> mcsim: not necessarily the most straightforward ones, but ones
+ you understand well
+ <braunr> keeping things simple is a way to keep control complexity in any
+ software
+ <braunr> as long as you understand, and decouple complicated things apart,
+ you can keep things simple
+ <braunr> nested functions doesn't have to do with complexity
+ <braunr> don't*
+ <braunr> it's just that, since they're not standard and commonly used
+ outside gnu projects, they're not well known
+ <braunr> i don't "master" them
+ <teythoon> also, they decouple the data flow from the control flow
+ <teythoon> which in my book is bad for imparative languages
+ <teythoon> and support for them in tools like gdb is poor
+ <mcsim> braunr: I remembered nested functions because now I use C++ and I
+ question myself if I may use all these C++ facilities, like lambdas,
+ complicated templates and other stuff.
+ <mcsim> kilobug: And using only things that you understand well sounds
+ straightforward and logical
+ <braunr> that's why i don't write c++ code :)
+ <braunr> it's very complicated and requires a lot of effort for the
+ developer to actually master it
+ <braunr> mcsim: you can use those features, but sparsely, when they really
+ do bring something useful
+
+
+# Leak Detection
+
+See *Leak Detection* on [[boehm_gc]].
diff --git a/open_issues/console_tty1.mdwn b/open_issues/console_tty1.mdwn
new file mode 100644
index 00000000..614c02c9
--- /dev/null
+++ b/open_issues/console_tty1.mdwn
@@ -0,0 +1,151 @@
+[[!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_hurd]]
+
+Seen in context of [[libpthread]], but probably not directly related to it.
+
+
+# IRC, freenode, #hurd, 2012-08-30
+
+ <gnu_srs> Do you also experience a frozen hurd console?
+ <braunr> yes
+ <braunr> i didn't check but i'm almost certain it's a bug in my branch
+ <braunr> the replacement of condition_implies was a bit hasty in some
+ places
+ <braunr> this is why i want to rework it separately
+
+
+## IRC, freenode, #hurd, 2012-09-03
+
+ <gnu_srs> braunr: Did you find the cause of the Hurd console freeze for
+ your libpthread branch?
+ <braunr> gnu_srs: like i said, a bug
+ <braunr> probably in the replacement of condition_implies
+ <braunr> i rewrote that part in libpipe and it no works
+ <braunr> now*
+
+ <braunr> gnu_srs: the packages have been updated
+ <braunr> and these apparently fix the hurd console issue correctly
+
+## IRC, freenode, #hurd, 2012-09-04
+
+ <braunr> gnu_srs: this hurd console problem isn't fixed
+ <braunr> it seems to be due to a race condition that only affects the first
+ console
+ <braunr> and by reading the code i can't see how it can even work oO
+ <gnu_srs> braunr: just rebooted, tty1 is still locked, tty2-6 works. And
+ the floppy error stays (maybe a kvm bug??)
+ <braunr> the floppy error is probably a kvm bug as we discussed
+ <braunr> the tty1 locked isn't
+ <braunr> i have it too
+ <braunr> it seems to be a bug in the hurd console server
+ <braunr> which is started by tty1, but for some reason, doesn't return a
+ valid answer at init time
+ <braunr> if you kill the term handling tty1, you'll see your first tty
+ starts working
+ <braunr> for now i'll try a hack that starts the hurd console server before
+ the clients
+ <braunr> doesn't work eh
+ <braunr> tty1 is the only one started before runttys
+ <braunr> indeed, fixing /etc/hurd/runsystem.gnu so that it doesn't touch
+ tty1 fixes the problem
+ <gnu_srs> do you have an explanation?
+ <braunr> not really no
+ <braunr> but it will do for now
+ <pinotree> samuel added that with the comment above, apparently to
+ workaround some other issue of the hurd console
+ <braunr> i'm pretty sure the bug is already visible with cthreads
+ <braunr> the first console always seems weird compared to the others
+ <braunr> with a login: at the bottom of the screen
+ <braunr> didn't you notice ?
+ <pinotree> sometimes, but not often
+ <braunr> typical of a race
+ <pinotree> (at least for me)
+ <braunr> pthreads being slightly slower exposes it
+ <gnu_srs> confirmed, it works by commenting out touch /dev/tty1
+ <gnu_srs> yes, the login is at the bottom of the screen, sometimes one in
+ the upper part too:-/
+ <braunr> so we have a new open issue
+ <braunr> hm
+ <braunr> exiting the first tty doesn't work
+ <braunr> which makes me think of the issue we have with screen
+ <gnu_srs> confirmed!
+ <braunr> also, i don't understand why we have getty on tty1, but nothing on
+ the other terminals
+ <braunr> something is really wrong with terminals on hurd *sigh*
+ <braunr> ah, the problem looks like it happens when getty attempts to
+ handle a terminal !
+ <braunr> gnu_srs: anyway, i don't think it should be blocking for the
+ conversion to pthreads
+ <braunr> but it would be better if someone could assign himself that bug
+ <braunr> :)
+
+
+## IRC, freenode, #hurd, 2012-09-05
+
+ <antrik> braunr: the login at the bottom of the screen if from the Mach
+ console I believe
+ <braunr> antrik: well maybe, but it shouldn't be there anyway
+ <antrik> braunr: why not?
+ <antrik> it's confusing, but perfectly correct as far as I can tell
+ <braunr> antrik: two login: on the same screen ?
+ <braunr> antrik: it's even more confusing when comparing with other ttys
+ <antrik> I mean it's correct from a techincal point of view... I'm not
+ saying it's helpful for the user ;-)
+ <braunr> i'm not even sure it's correct
+ <braunr> i've double checked the pthreads patch and didn't see anything
+ wrong there
+ <antrik> perhaps the startup of the Hurd console could be delayed a bit to
+ make sure it happens after the Mach console login is done printing
+ stuff...
+ <braunr> why are our gettys stubs ?
+ <antrik> I never understood the point of a getty TBH...
+ <braunr> well you need to communicate to something behind your terminal,
+ don't you ?
+ <braunr> with*
+ <antrik> why not just launch the login program or login shell right away?
+ <braunr> what if you want something else than a login program ?
+ <antrik> like what?
+ <antrik> and how would a getty help with that?
+ <braunr> an ascii-art version of star wars
+ <braunr> it would be configured to start something else
+ <antrik> and why does that need a getty? why not just start something else
+ directly?
+ <braunr> well getty is about the serial line parameters actually
+ <antrik> yeah, I had a vague understanding that it has something to do with
+ serial lines (or real TTY lines)... but we hardly need that on local
+ cosoles :-)
+ <antrik> consoles
+ <braunr> right
+ <braunr> but then why even bother with something like runttys
+ <antrik> well, something has to start the terminal servers?...
+ <antrik> I might be confused though
+ <braunr> what i don't understand is
+ <braunr> why is there no getty at startup, whereas they are spawned when
+ logging off ?
+ <antrik> they are? that's fascinating indeed ;-)
+ <braunr> does it behave like this on your old version ?
+ <antrik> I don't remember ever having seen a "getty" process on my Hurd
+ systems...
+ <braunr> can you log on e.g. tty2 and then log out, and see ?
+ <antrik> OTOH, I'm hardly ever using consoles...
+ <antrik> hm... I think that should be possible remotely using the console
+ client with ncurses driver? never tried that...
+ <braunr> ncurses driver ?
+ <braunr> hum i don't know, never tried either
+ <braunr> and it may add other bugs :p
+ <braunr> better wait to be close to the machine
+ <antrik> hehe
+ <antrik> well, it's a good excuse for trying the ncurses driver ;-)
+ <antrik> hrm
+ <antrik> alien:~# console -d ncursesw
+ <antrik> console: loading driver `ncursesw' failed: Gratuitous error
+ <antrik> I guess nobody tested that stuff in years
diff --git a/open_issues/console_vs_xorg.mdwn b/open_issues/console_vs_xorg.mdwn
new file mode 100644
index 00000000..ffefb389
--- /dev/null
+++ b/open_issues/console_vs_xorg.mdwn
@@ -0,0 +1,31 @@
+[[!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]]
+
+
+# IRC, freenode, #hurd, 2012-08-30
+
+ <gean> braunr: I have some errors about keyboard in the xorg log, but
+ keyboard is working on the X
+ <braunr> gean: paste the log somewhere please
+ <gean> braunr: http://justpaste.it/19jb
+ [...]
+ [1987693.272] Fatal server error:
+ [1987693.272] Cannot set event mode on keyboard (Inappropriate ioctl for device)
+ [...]
+ [1987693.292] FatalError re-entered, aborting
+ [1987693.302] can't reset keyboard mode (Inappropriate ioctl for device)
+ [...]
+ <braunr> hum
+ <braunr> it looks like the xorg keyboard driver evolved and now uses ioctls
+ our drivers don't implement
+ <braunr> thanks for the report, we'll have to work on this
+ <braunr> i'm not sure the problem is new actually
diff --git a/open_issues/contributing.mdwn b/open_issues/contributing.mdwn
new file mode 100644
index 00000000..7ae742f0
--- /dev/null
+++ b/open_issues/contributing.mdwn
@@ -0,0 +1,44 @@
+[[!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_documentation]]
+
+This should be integrated into [[/contributing]].
+
+---
+
+Every now and then, people show up who have an inward urge to contribute to the
+GNU Hurd, but have some difficulties about how to do that.
+
+For example, IRC, #hurd, 2010-10-06:
+
+ <rah> I find it difficult to find the will to contribute to the hurd while hurd != hurd-ng
+ <pochu> hurd-ng?
+ <pochu> ah, http://www.gnu.org/software/hurd/hurd/ng.html
+ <pochu> rah: you may want to work on achieving that then
+ <rah> pochu: I'm not in a position to do OS research
+ <antrik> rah: if you are not into OS research, why do you need it to be ngHurd? :-)
+ <rah> antrik: I don't want to work on software which I know is already obsolete
+ <tschwinge> rah: My position on that can be found here; you may want to think about it. http://lists.gnu.org/archive/html/bug-hurd/2007-07/msg00111.html
+ <antrik> rah: the existing Hurd implementation is not any more obsolete than any other large software project
+ <antrik> there are always things that could be redone in a better way some time in the future
+ <antrik> but we have to start somewhere
+ <antrik> software development is a dynamic process
+ <antrik> trying to come up with a perfect design before you write any code will never lead anywhere, ever
+ <rah> antrik: of course, but when you know your start is wrong, have identified its problems, and are in the process of designing a second attempt, working on the first seems pointless
+ <antrik> rah: well, do you know all these things? because I do not
+ <antrik> what the experiments with new Hurd designs proved so far is that nobody is in a position to claim, "I have a better design"
+ <antrik> it's not hard to come up with a design that is better in some points -- but it's damn hard to come up with one that's not lacking in others
+ <antrik> the existing Hurd design is actually the only one which we *know* to work
+ <antrik> while research on improving the design is certainly beneficial, it's not like there is something new ready to replace the existing design at any moment
+ <antrik> and frankly, I'm more and more convinced that only iterative changes can ever result in any real improvement
+ <antrik> (and doing these changes requires a certain momentum, which we will never gain unless we actually have something usable first)
+ <LarstiQ> rah: afaik, not much is being done of designing another attempt
+ <rah> antrik: yes, I know all these things
diff --git a/open_issues/crash_server.mdwn b/open_issues/crash_server.mdwn
new file mode 100644
index 00000000..3d656082
--- /dev/null
+++ b/open_issues/crash_server.mdwn
@@ -0,0 +1,270 @@
+[[!meta copyright="Copyright © 2009, 2010, 2011, 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]]."]]"""]]
+
+[[!tag open_issue_hurd]]
+
+Given an `a.out` executable that only does `raise (SIGABRT)`, invoking that
+one...
+
+ * ... against `crash-dump-core` will...
+
+ * ... not overwrite existing `core` files.
+
+ Is this reasonable? Linux does overwrite them, for example.
+
+ * ... show big variances in running-time behavior:
+
+ $ TIMEFORMAT='real %R user %U system %S'
+ $ rm -f core; time env CRASHSERVER=/servers/crash-dump-core ./a.out; ls -l core
+ Aborted (core dumped)
+ real 1.350 user 0.000 system 0.010
+ -rw------- 1 tschwinge tschwinge 17031168 Jul 7 21:59 core
+ $ rm -f core; time env CRASHSERVER=/servers/crash-dump-core ./a.out; ls -l core
+ Aborted (core dumped)
+ real 22.771 user 0.000 system 0.010
+ -rw------- 1 tschwinge tschwinge 17031168 Jul 7 21:59 core
+ $ rm -f core; time env CRASHSERVER=/servers/crash-dump-core ./a.out; ls -l core
+ Aborted (core dumped)
+ real 1.367 user 0.000 system 0.010
+ -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:00 core
+ $ rm -f core; time env CRASHSERVER=/servers/crash-dump-core ./a.out; ls -l core
+ Aborted (core dumped)
+ real 5.789 user 0.000 system 0.010
+ -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:00 core
+ $ rm -f core; time env CRASHSERVER=/servers/crash-dump-core ./a.out; ls -l core
+ Aborted (core dumped)
+ real 22.664 user 0.010 system 0.000
+ -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:01 core
+
+ * ... produce a huge `core` file:
+
+ $ du -hs core
+ 17M core
+
+ On Linux, the `core` file occupies 76 KiB of disk space, which seems
+ much more reasonable. This is possibly related with the default 128MiB
+ heap preallocation.
+
+ * ... does not always produce a useful backtrace:
+
+ `abort();`
+
+ $ gdb test core
+ warning: core file may not match specified executable file.
+ [New Thread 86678]
+ warning: Wrong size fpregset in core file.
+ ...
+ Core was generated by `./test'.
+ Program terminated with signal 6, Aborted.
+ warning: Wrong size fpregset in core file.
+ (gdb) bt
+ #0 0x00000000 in ?? ()
+ #1 0x011f593f in __msg_sig_post (process=72, signal=6, sigcode=0, refport=1)
+ at /build/buildd-eglibc_2.10.2-7-hurd-i386-iGL6op/eglibc-2.10.2/build-tree/hurd-i386-libc/hurd/RPC_msg_sig_post.c:144
+ #2 0x0109a433 in kill_port (pid=<value optimized out>)
+ at ../sysdeps/mach/hurd/kill.c:68
+ #3 kill_pid (pid=<value optimized out>) at ../sysdeps/mach/hurd/kill.c:105
+ #4 0x0109a69f in __kill (pid=21142, sig=6) at ../sysdeps/mach/hurd/kill.c:139
+ #5 0x01099af6 in raise (sig=6) at ../sysdeps/posix/raise.c:27
+ #6 0x0109de59 in abort () at abort.c:88
+ #7 0x0804849f in main ()
+
+ `char *foo = 0; *foo = 1;`
+
+ $ gdb test core
+ Program terminated with signal 11, Segmentation fault.
+ warning: Wrong size fpregset in core file.
+ #0 0x00000000 in ?? ()
+ (gdb) bt
+ #0 0x00000000 in ?? ()
+ #1 0x0108565b in __libc_start_main (main=0x8048464 <main>, argc=1, ubp_av=0x1023e64,
+ init=0x8048490 <__libc_csu_init>, fini=0x8048480 <__libc_csu_fini>, rtld_fini=0xea20 <_dl_fini>,
+ stack_end=0x1023e5c) at libc-start.c:251
+ #2 0x080483d1 in _start ()
+
+ `raise (SIGABRT);`
+
+ $ gdb a.out core
+ warning: core file may not match specified executable file.
+ [New Thread 76651]
+
+ warning: Wrong size fpregset in core file.
+ Reading symbols from /lib/libc.so.0.3...[...]
+ Core was generated by `./a.out'.
+ Program terminated with signal 6, Aborted.
+
+ warning: Wrong size fpregset in core file.
+ #0 0x00000000 in ?? ()
+ (gdb) bt
+ #0 0x00000000 in ?? ()
+ Cannot access memory at address 0x17
+
+ [[!tag open_issue_gdb]] Probably [[GDB]] doesn't manage to dig in the stack properly.
+
+ * ... against `crash-suspend` will...
+
+ * ... not work at all:
+
+ $ CRASHSERVER=/servers/crash-suspend ./a.out
+ $ [returns to the shell and doesn't suspended]
+
+ * ... show big variances in running-time behavior:
+
+ $ TIMEFORMAT='real %R user %U system %S'
+ $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core
+ Aborted (core dumped)
+ real 1.381 user 0.000 system 0.010
+ -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:04 core
+ $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core
+ Aborted (core dumped)
+ real 1.332 user 0.000 system 0.010
+ -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:04 core
+ $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core
+ Aborted (core dumped)
+ real 21.228 user 0.000 system 0.010
+ -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:04 core
+ $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core
+ Aborted (core dumped)
+ real 1.323 user 0.000 system 0.010
+ -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:05 core
+ $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core
+ Aborted (core dumped)
+ real 22.279 user 0.000 system 0.010
+ -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:05 core
+ $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core
+ Aborted (core dumped)
+ real 1.362 user 0.000 system 0.000
+ -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:08 core
+ $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core
+ Aborted (core dumped)
+ real 21.110 user 0.000 system 0.000
+ -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:08 core
+ $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core
+ Aborted (core dumped)
+ real 1.350 user 0.000 system 0.020
+ -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:08 core
+
+ * ... can reliably crash GNU Mach:
+
+ This happens if a `core` file is already present (and won't get
+ overwritten; see above). I reproduced this three times.
+
+ $ TIMEFORMAT='real %R user %U system %S'
+ $ time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core
+ Aborted
+ real 2.856 user 0.000 system 0.010
+ -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:08 core
+
+ panic: zalloc: zone kalloc.8192 exhausted
+ Kernel Breakpoint trap, eip 0x20020a77
+ Stopped at 0x20020a76: int $3
+ db> trace
+ 0x20020a76(2006aba8,4d0f7e9c,200209b0,0,0)
+ 0x20020a4d(2006b094,2006ae40,2000,20016803,4a5f4114)
+ 0x2002bca5(49a03564,1,0,9,1000)
+ 0x20022f4c(2000,4a5f45d4,4a84879c,49a46564,4ac43e78)
+ 0x20021e65(4ac43e78,4a5f45d4,4a5f4114,0,0)
+ 0x2005309d(2106ba9c,3,38,28,1783)
+ Bad frame pointer: 0x2106ba78
+
+ $ addr2line -i -f -e /boot/gnumach-xen 0x20020a76 0x20020a4d 0x2002bca5 0x20022f4c 0x20021e65 0x2005309d
+ Debugger
+ /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/debug.c:105
+ panic
+ /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/debug.c:148
+ zalloc
+ /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/zalloc.c:470
+ kalloc
+ /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/kalloc.c:185
+ ipc_kobject_server
+ /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/ipc_kobject.c:76
+ mach_msg_trap
+ /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/ipc/mach_msg.c:1367
+
+
+# IRC, freenode, #hurd, 2013-09-07
+
+ <rekado> I'm trying to investigate a crash in pfinet, so it will actually
+ die. I just want to know why it dies and what the value of a few
+ variables has been when it died.
+ <teythoon> have you tried to make it dump core?
+ <rekado> oh, good idea.
+ <rekado> I'll try that.
+ <teythoon> do you know how?
+ <rekado> I don't, but I think I can figure it out.
+ <teythoon> look into /servers
+ <rekado> do I just have to set CRASHSERVER=/servers/crash-dump-core and run
+ pfinet in that environment?
+ <teythoon> possibly, I've never heard of CRASHSERVER, but it's certainly
+ plausible ;)
+ <teythoon> I just link crash to crash-dump-core, that way it is permanent
+ and for all processes
+ <rekado> found it in the website contents
+ <rekado> gotta try that.
+ <rekado> hmm, I can't get pfinet to dump core; linked /servers/crash to
+ /servers/crash-dump-core and compiled pfinet to raise(6) at one point.
+ <rekado> But no core file is created.
+ <teythoon> :/
+ <teythoon> rekado: try cd /tmp ; cat & kill -SIGILL %% to see if that dumps
+ core
+ <rekado> yes, this works.
+ <rekado> I replaced the original pfinet with my crashing version.
+ <rekado> Should it dump core to /hurd then?
+ <teythoon> I'm not sure about it's wd
+ <teythoon> hm, ok, I just did settrans -ca foo /hurd/pfinet and then killed
+ that pfient with SIGILL and it dumped core
+ <teythoon> to the directory I issued the settrans from
+ <rekado> So I must run it myself. I can't just replace the original binary
+ and have it dump core somewhere.
+ <teythoon> it seems that you have to use settrans -ca to start an active
+ translator
+ <teythoon> do fsysopts /servers/socket/2 to find out the cmdline of your
+ pfinet
+ <rekado> that's very helpful.
+ <rekado> thanks
+ <teythoon> then use this to restart it, e.g.:
+ <teythoon> settrans -afg /servers/socket/2 $(fsysopts /servers/socket/2)
+ <teythoon> if it dies it should dump core to you cwd
+ <rekado> great. Thank you very much. I had been wondering how to get the
+ full cmdline of pfinet.
+ * rekado makes a note of fsysopts
+ <rekado> yup, there's the core file. Nice.
+ <teythoon> cool 8D
+ <teythoon> btw, in case using gdb doesn't work out for your problem, if you
+ start pfinet (or any translator) this way (with -a == active), you can
+ write stuff to stderr
+ <rekado> yeah, I noticed that. The assert() call wrote to stderr. Useful.
+ <braunr> rekado: core dumps are another not-working-well feature of the
+ hurd :/
+ <braunr> i recommend attaching
+ <tschwinge> rekado: In case that's still helpful:
+ <http://www.gnu.org/software/hurd/hurd/debugging/translator.html>.
+
+
+# IRC, freenode, #hurd, 2013-12-14
+
+ <gnu_srs> How to get a core dump?
+ <teythoon> either set CRASHSERVER to /servers/crash-dump-core for the
+ process you want the core file of
+ <teythoon> or make /servers/crash point to crash-dump-core to make this the
+ default for all processes
+ <gnu_srs> does it work now, it did not before?
+ <teythoon> it does for me, never had issues
+ <gnu_srs> k!
+ <teythoon> well, i believe the second option has issues
+ <teythoon> if two processes crash, both may write/create a file in the same
+ location
+
+
+---
+
+If someone is working in this area, they may want to have a look at
+[[GDB_gcore]], and port <http://code.google.com/p/google-coredumper/>, too.
diff --git a/open_issues/crashes_vs_system_load_cpu_load_rpc_load.mdwn b/open_issues/crashes_vs_system_load_cpu_load_rpc_load.mdwn
new file mode 100644
index 00000000..4076d8d0
--- /dev/null
+++ b/open_issues/crashes_vs_system_load_cpu_load_rpc_load.mdwn
@@ -0,0 +1,17 @@
+[[!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]]."]]"""]]
+
+IRC, unknown channel, unknown date:
+
+ <antrik> I have a theory
+ <antrik> when the system is under CPU load, the ext2 locking issues are more likely to happen
+ <antrik> I'm under the impression, that when doing something disk-intensive (like a compile job) *considerably* more often causes crashes, when doing *any* other activity in parallel -- be it other compile jobs, or CPU-only activities
+ <antrik> thinking about it, I'm not sure whether CPU-intensive is the decisive criterium, or maybe RPC-intensive...
+ <antrik> CPU load doesn't seem to have any effect -- neither alone, nor in combination with other testcases
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
new file mode 100644
index 00000000..b94c0c1d
--- /dev/null
+++ b/open_issues/crt0_o_crt1_o_debug_info_relocation_invalid_symbol_index.mdwn
@@ -0,0 +1,41 @@
+[[!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
new file mode 100644
index 00000000..67b64651
--- /dev/null
+++ b/open_issues/cvs_tasks_file.mdwn
@@ -0,0 +1,18 @@
+[[!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/cvs_todo_file.mdwn b/open_issues/cvs_todo_file.mdwn
new file mode 100644
index 00000000..a42e6dca
--- /dev/null
+++ b/open_issues/cvs_todo_file.mdwn
@@ -0,0 +1,18 @@
+[[!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 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.
diff --git a/open_issues/dbus.mdwn b/open_issues/dbus.mdwn
new file mode 100644
index 00000000..b3bebf48
--- /dev/null
+++ b/open_issues/dbus.mdwn
@@ -0,0 +1,502 @@
+[[!meta copyright="Copyright © 2011, 2012, 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]]."]]"""]]
+
+[[!tag open_issue_hurd]]
+
+The dbus problems are due to missing scm credentials [[sendmsg_scm_creds]] and socket credentials
+[[pflocal_socket_credentials_for_local_sockets]]. There was also a problem with short timeout in
+[[select]], but that has been solved in Debian by setting a minimum timeout of 1ms.
+
+[[!toc]]
+
+
+# IRC, freenode, #hurd, 2011-11-26
+
+ <antrik> BTW, how much effort is necessary to fix dbus?
+ <pinotree> basically, have pflocal know who's the sender
+ (pid/uid/gid/groups) in the socket send op
+
+
+# IRC, freenode, #hurd, 2011-12-16
+
+ <braunr> pinotree: what's the problem with dbus ?
+ <pinotree> braunr: select() returning 0 changed fd's with very short (eg <
+ 1ms) timeouts when there are actually events;
+
+[[select]].
+
+ <pinotree> and missing socket credentials
+
+[[sendmsg_scm_creds]].
+
+ <braunr> oh
+ <braunr> which socket creds interface ?
+ <pinotree> bsd, i.e. with SCM_CREDENTIALS payload for cmsg on
+ {recv,send}msg()
+ <braunr> ok
+ <braunr> SCM_RIGHTS too ?
+ <braunr> the select issue seems weird though
+ <pinotree> hm no, that's for passing fd's to other processes
+ <braunr> is it specific to pflocal or does dbus use pfinet too ?
+ <pinotree> iirc on very short timeouts the application has no time waiting
+ for the reply of servers
+ <braunr> i see
+ <pinotree> braunr: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=79358
+ <braunr> thanks
+ <pinotree> (the interesting messages are from #53 and on)
+ <braunr> 2000 eh ... :)
+ <braunr> hm i agree with neal, i don't understand why the timeout is given
+ to the kernel as part of the mach_msg call
+
+
+# IRC, freenode, #hurd, 2011-12-20
+
+ <braunr> hm, i don't see any occurrence of SCM_CREDENTIALS in dbus
+ <braunr> only SCM_RIGHTS
+ <pinotree> braunr: yes, that one
+ <braunr> oh
+ <braunr> i thought you said the opposite last time
+ <pinotree> dbus/dbus-sysdeps-unix.c, write_credentials_byte and
+ _dbus_read_credentials_socket (with #define HAVE_CMSGCRED)
+ <braunr> hm
+ <braunr> which version ?
+ <braunr> i don't see anything in 1.4.16
+ <pinotree> 1.4.16
+ <braunr> grmbl
+ <braunr> ah, i see
+ <braunr> SCM_CREDS
+ <pinotree> if you want, i have a simplier .c source with it
+ <braunr> no i'm just gathering info
+ <pinotree> ok
+ <braunr> what's the deal with SCM_CREDS and SCM_CREDENTIALS ?
+ <braunr> bsd vs sysv ?
+ <braunr> oh, http://lists.debian.org/debian-hurd/2002/03/msg00135.html
+ <braunr> so we actually do want both SCM_CREDS and SCM_RIGHTS for debus
+ <braunr> dbus
+ <pinotree> SCM_RIGHTS is a different matter, it is for passing fd's
+ <braunr> yes
+ <braunr> but it's used by dbus
+ <braunr> so if we can get it, it should help too
+ <pinotree> there's a preliminary patch for it done by emilio time ago, and
+ iirc it's applied to debian's glibc
+ <braunr> ah, he changed the libc
+ <braunr> right, that's the only sane way
+ <pinotree> iirc roland didn't like one or more parts of it (but i could be
+ wrong)
+ <braunr> ok
+
+
+# IRC, freenode, #hurd, 2013-07-17
+
+ <teythoon> btw pinotree, what happened to your efforts to make dbus work?
+ <pinotree> not much, my initial patch was just a crude hack, a better
+ solution requires more thinkering and work
+ <teythoon> yes, ive seen that
+ <teythoon> but that was only a tiny patch against the libc, surely there
+ must be more to that?
+ <pinotree> not really
+ <teythoon> and the proper fix is to patch pflocal to query the auth server
+ and add the credentials?
+ <pinotree> possibly
+ <teythoon> that doesn't sound to bad, did you give it a try?
+ <pinotree> not really, got caught in other stuff
+
+
+# IRC, freenode, #hurd, 2013-09-02
+
+ <gnu_srs1> something is wrong with libc0.3 since the switch to 2.17. dbus
+ does not run any longer when rebuilt
+ <gnu_srs1> the latest build of dbus was with 2.13: libc0.3-dev: already
+ installed (2.13-38)
+ <pinotree> debug it
+ <gnu_srs1> Yes, I will. Maybe somebody could rebuild it and verify my
+ findings?
+ <pinotree> gnu_srs1: your finding is "doesn't work", which is generic and
+ does not help without investigation
+ <gnu_srs1> just rebuild it and: e.g. ./build-debug/bus/dbus-daemon --system
+ (--nofork)
+ <pinotree> gnu_srs1: please, debug it
+ <gnu_srs1> I have partially already. But maybe the problems only shows on
+ my box. I'll rebuild on another box before continuing debugging.
+ <pinotree> gnu_srs1: are you, by chance, running a libc or something else
+ with your scm_creds work?
+ <gnu_srs1> I did, but I've backed to 2.17-92 right now.
+ <gnu_srs1> sane problem with dbus on another box, something's fishy:-(
+ <gnu_srs1> braunr: any good way to find out if the dbus problems are with
+ libpthread? Setting a breakpoint with libc0.3-dbg installed.
+ <braunr> gnu_srs1: i don't know
+
+See [[glibc]], *Missing interfaces, amongst many more*, *`SOCK_CLOEXEC`*.
+
+
+# IRC, freenode, #hurd, 2013-09-04
+
+ <gnu_srs> Hi, looks like dbus requires abstract socket namespace: #undef
+ HAVE_ABSTRACT_SOCKETS What's missing?
+ <pinotree> uh?
+ <pinotree> abstract unix sockets are a Linux feature, and surely it is not
+ mandatory for dbus
+ <gnu_srs> Looks like dbus exits if they are not supported:
+ <gnu_srs> dbus_set_error (error, DBUS_ERROR_NOT_SUPPORTED, "Operating
+ system does not support abstract socket namespace\n");   _dbus_close
+ (listen_fd, NULL); 1061  return -1;
+ <pinotree> that is enclosed in a if (abstract)
+ <pinotree> and that parameter is set to true in other places (eg
+ dbus/dbus-server-unix.c) only when HAVE_ABSTRACT_SOCKETS is defined
+ <pinotree> so no, abstract sockets are not mandatory
+ <gnu_srs> Well this code is executed e.g. when running emacs remotely in
+ X. Have to dig deeper then to see why.
+ <pinotree> maybe it could have to do the fact that your dbus server is
+ running in linux and runs by default using such sockets type
+ <pinotree> but yes, you need to dig better
+ <gnu_srs> pinotree: You are right. when running natively the problem is:
+ <pinotree> *drums*
+ <gnu_srs> Manually: Process /usr/lib/at-spi2-core/at-spi-bus-launcher
+ exited with status 1
+ <pinotree> eh?
+ <gnu_srs> Error retrieving accessibility bus address:
+ org.freedesktop.DBus.Error.Spawn.ChildExited: ^
+ <pinotree> most probably that service does not start due to the lack of
+ socket credentials which affects dbus
+ <pinotree> uninstall or disable those additional services, they are not
+ your problem
+ <gnu_srs> credentials is enabled. which services to remove?
+ <pinotree> dunno
+
+
+# IRC, freenode, #hurd, 2013-09-11
+
+ <gnu_srs> Hi, looks like frebsd had (2008) the same problem as hurd when
+ sending credentials over PF_INET:
+ <gnu_srs>
+ http://lists.freebsd.org/pipermail/freebsd-hackers/2008-May/024577.html
+ <gnu_srs> Since the dbus code is about the same now (2013), maybe they
+ added support?
+ <gnu_srs> The next message in the thread confirms that the dbus code is
+ invalid, does anybody have pointers?
+ <pinotree> from what i've seen so far, socket credentials are done only for
+ local sockets (ie PF_UNIX)
+ <pinotree> i don't see how things like uid/gid/pid of the socket endpoint
+ can have anything to do with AF_INET
+ <pinotree> and socket credentials in dbus are used only in the [local]
+ socket transport, so there's no issue
+
+
+# IRC, freenode, #hurd, 2013-09-12
+
+ <gnu_srs> pinotree: Yes, there is an issue with dbus and AF_INET, see
+ test/corrupt.c: tests /corrupt/tcp and /corrupt/byte-order/tcp:-/
+ <pinotree> gnu_srs: what's wrong with those? they are just testing the
+ connection over a tcp socket
+ <pinotree> as said above, socket credentials shouldn't be used in such
+ cases
+ <gnu_srs> They are, see also test/relay.c: /relay and /limit tests:-(
+ <pinotree> how are they?
+ <pinotree> please be more specifc...
+ <gnu_srs> Just run the tests yourself with DBUS_VERBOSE=1
+ <pinotree> you are claiming there is a problem, so please specify what is
+ the actual issue
+ <gnu_srs> DBUS_VERBOSE=1 build-debug/test/test-relay
+ <pinotree> you are claiming there is a problem, so please specify what is
+ the actual issue
+ <gnu_srs> same with test-corrupt
+ <gnu_srs> look at the verbose output: Failed to write credentials: Failed
+ to write credentials byte: Invalid argument
+ <gnu_srs> coming from pfinet since PF_INET is used.
+ <pinotree> check what it does on linux then
+ <pinotree> put an abort() at the start of the read/write socket credential
+ functions in dbus-sysdeps-unix.c and see whether it is triggered also on
+ linux
+ <gnu_srs> SO_PEERCRED is used for linux and LOCAL_CREDS is used for
+ kfreebsd, so we are on our own here:-/
+ <pinotree> and linux' SO_PEERCRED works also on AF_INET sockets? i'd doubt
+ it
+ <gnu_srs>
+ http://stackoverflow.com/questions/10037086/so-peercred-vs-scm-credentials-why-there-are-both-of-them
+ <pinotree> yes, i know the difference, but please read what i asked again
+ <gnu_srs> I'll check to be sure...
+ <braunr> gnu_srs: user credentials are not supposed to be passed through an
+ AF_INET socket
+ <braunr> how hard is that to understand ?
+ <gnu_srs> OK, linux use send since CMSGCREDS is not defined to write
+ credentials. Working on how they are received.
+ <gnu_srs> braunr: I do understand, but the dbus code tries to do that for
+ Hurd:-(
+ <pinotree> then it should do that on linux too
+ <pinotree> (since the local socket credentials code is isolated in own
+ functions, and they are called only for the unix transport)
+ <gnu_srs> Happiness:-D, almost all dbus tests pass!
+ <gnu_srs> 17(17) dbus tests pass:)
+ <braunr> gnu_srs: hopefully your patch does things right
+ <gnu_srs> which patch
+ <braunr> adding credentials through unix socket
+ <braunr> isn't that what you're doing ?
+ <gnu_srs> the mail to MLs is from the stock installed packages.
+ <braunr> ?
+ <gnu_srs> the test reports are with the SCM_CREDS patches, but I stumbled
+ on the SCM_RIGHTS issues reported to MLs
+ <gnu_srs> no patches applied, just test the attached file yourself.
+ <braunr> so what's your work about ?
+ <gnu_srs> I'm working on SCM_CREDS, yes, and created patches for dbus,
+ glib2.0 and libc.
+ <gnu_srs> the mail was about some bug in the call to io_restrict_auth in
+ sendmsg.c: without any of my patches applied (another image)
+ <teythoon> gnu_srs: you have to give us more context, how are we supposed
+ to know how to find this sendmsg.c file?
+ <pinotree> (it's in glibc, but otherwise the remark is valid)
+ <pinotree> s/otherwise/anyway/
+
+
+# Emails
+
+# IRC, freenode, #hurd, 2013-10-16
+
+ <braunr> gnu_srs: how could you fail to understand credentials need to be
+ checked ?
+ <gnu_srs> braunr: If data is sent via sendmsg, no problem, right?
+ <braunr> gnu_srs: that's irrelevant
+ <gnu_srs> It's just to move the check to the receive side.
+ <braunr> and that is the whole problem
+ <braunr> it's not "just" doing it
+ <braunr> first, do you know what the receive side is ?
+ <braunr> do you know what it can be ?
+ <braunr> do you know where the corresponding source code is to be found ?
+ <gnu_srs> please, describe a scenario where receiving faulty ancillary data
+ could be a problem instead
+ <braunr> dbus
+ <braunr> a user starting privileged stuff although he's not part of a
+ privileged group of users for example
+ <braunr> gnome, kde and others use dbus to pass user ids around
+ <braunr> if you can't rely on these ids being correct, you can compromise
+ the whole system
+ <braunr> because dbus runs as root and can give root privileges
+ <braunr> or maybe not root, i don't remember but a system user probably
+ <pinotree> "messagebus"
+ <gnu_srs> k!
+ <braunr> see http://www.gnu.org/software/hurd/open_issues/dbus.html
+ <braunr> IRC, freenode, #hurd, 2013-07-17
+ <braunr> <teythoon> and the proper fix is to patch pflocal to query the
+ auth server and add the credentials?
+ <braunr> <pinotree> possibly
+ <braunr> <teythoon> that doesn't sound to bad, did you give it a try?
+
+
+# IRC, freenode, #hurd, 2013-10-22
+
+ <gnu_srs> I think I have a solution on the receive side for SCM_CREDS :)
+
+ <gnu_srs> A question related to SCM_CREDS: dbus use a zero data byte to get
+ credentials sent.
+ <gnu_srs> however, kfreebsd does not care which data (and credentials) is
+ sent, they report the credentials anyway
+ <gnu_srs> should the hurd implementation do the same as kfreebsd?
+ <youpi> gnu_srs: I'm not sure to understand: what happens on linux then?
+ <youpi> does it see zero data byte as being bogus, and refuse to send the
+ creds?
+ <gnu_srs> linux is also transparent, it sends the credentials independent
+ of the data (but data has to be non-null)
+ <youpi> ok
+ <youpi> anyway, what the sending application writes does not matter indeed
+ <youpi> so we can just ignore that
+ <youpi> and have creds sent anyway
+ <braunr> i think the interface normally requires at least a byte of data
+ for ancilliary data
+ <youpi> possibly, yes
+ <braunr> To pass file descriptors or credentials over a SOCK_STREAM,
+ you need to send or
+ <braunr> receive at least one byte of non-ancillary data in
+ the same sendmsg(2) or
+ <braunr> recvmsg(2) call.
+ <braunr> but that may simply be linux specific
+ <braunr> gnu_srs: how do you plan on implementing right checking ?
+ <gnu_srs> Yes, data has to be sent, at least one byte, I was asking about
+ e.g. sending an integer
+ <braunr> just send a zero
+ <braunr> well
+ <braunr> dbus already does that
+ <braunr> just don't change anything
+ <braunr> let applications pass the data they want
+ <braunr> the socket interface already deals with port rights correctly
+ <braunr> what you need to do is make sure the rights received match the
+ credentials
+ <gnu_srs> The question is to special case on a zero byte, and forbid
+ anything else, or allow any data.
+ <braunr> why would you forbid
+ <braunr> ?
+ <gnu_srs> linux and kfreebsd does not special case on a received zero byte
+ <braunr> same question, why would you want to do that ?
+ <gnu_srs> linux sends credentials data even if no SCM_CREDENTIALS structure
+ is created, kfreebsd don't
+ <braunr> i doubt that
+ <gnu_srs> To be specific:msgh.msg_control = NULL; msgh.msg_controllen = 0;
+ <braunr> bbl
+ <gnu_srs> see the test code:
+ http://lists.debian.org/debian-hurd/2013/08/msg00091.html
+ <braunr> back
+ <braunr> why would the hurd include groups when sending a zero byte, but
+ only uid when not ?
+ <gnu_srs> ?
+ <braunr> 1) Sent credentials are correct:
+ <braunr> no flags: Hurd: OK, only sent ids
+ <braunr> -z Hurd: OK, sent IDs + groups
+ <braunr> and how can it send more than one uid and gid ?
+ <braunr> "sent credentials are not honoured, received ones are created"
+ <gnu_srs> Sorry, the implementation is changed by now. And I don't special
+ case on a zero byte.
+ <braunr> what does this mean ?
+ <braunr> then why give me that link ?
+ <gnu_srs> The code still applies for Linux and kFreeBSD.
+ <gnu_srs> It means that whatever you send, the kernel emits does not read
+ that data: see
+ <gnu_srs> socket.h: before struct cmsgcred: the sender's structure is
+ ignored ...
+ <braunr> do you mean receiving on a socket can succeed with gaining
+ credentials, although the sender sent wrong ones ?
+ <gnu_srs> Looks like it. I don't have a kfreebsd image available right now.
+ <gnu_srs> linux returns EPERM
+ <braunr> anyway
+ <braunr> how do you plan to implement credential checking ?
+ <gnu_srs> I'll mail patches RSN
+
+
+# IRC, freenode, #hurd, 2013-11-03
+
+ <gnu_srs> Finally, SCM_CREDS (IDs) works:) I was on the right track all the
+ time, it was just a small misunderstanding.
+ <gnu_srs> remains to solve the PID check
+ <youpi> gnu_srs: it should be a matter of adding
+ proc_user/server_authenticate
+ <gnu_srs> there are no proc_user/server_authenticate RPCs?
+ <gnu_srs> do you mean adding them to process.defs (and implement them)?
+ <youpi> gnu_srs: I mean that, yes
+
+
+# IRC, freenode, #hurd, 2013-11-13
+
+ <gnu_srs> BTW: I have to modify the SCM_RIGHTS patch to work together with
+ SCM_CREDS, OK?
+ <youpi> probably
+ <youpi> depends on what you change of course
+
+
+# IRC, freenode, #hurd, 2013-11-15
+
+ <gnu_srs> Hi, any ideas where this originates, gdb? warning: Error setting
+ exception port for process 9070: (ipc/send) invalid destination port
+ <braunr> gnu_srs: what's process 9070 ?
+ <gnu_srs> braunr: It's a test program for sending credentials over a
+ socket. Have to create a reproducible case, it's intermittent.
+ <gnu_srs> The error happens when running through gdb and the sending
+ program is chrooted:
+ <gnu_srs> -rwsr-sr-x 1 root root 21156 Nov 15 15:12
+ scm_rights+creds_send.chroot
+
+
+## IRC, freenode, #hurd, 2013-11-16
+
+ <gnu_srs> Hi, I have a problem debugging a suid program, see
+ http://paste.debian.net/66171/
+ <gnu_srs> I think this reveals a gnumach/hurd bug, it makes things behave
+ strangely for other programs.
+ <gnu_srs> How to get further on with this?
+ <gnu_srs> Or can't I debug a suid program as non-root?
+ <pochu> gnu_srs: if gdb doesn't work for setuid programs on hurd, I suppose
+ you could chmod -s the binary you're trying to debug, login as root and
+ run it under gdb
+ <gnu_srs> pochu: When logged in as root the program works, independent of
+ the s flag setting.
+ <pochu> right, probably the setuid has no effect in that case because your
+ effective uid is already fine
+ <pochu> so you don't hit the gdb bug in that case
+ <pochu> (just guessing)
+ <gnu_srs> It doesn't work in Linux either, so it might be futile.
+ <gnu_srs> trying
+ <pochu> hmm that may be the expected behaviour. after all, gdb needs to be
+ priviledged to debug priviledged processes
+ <gnu_srs> Problem is that it was just the suid properties I wanted to
+ test:(
+ <braunr> gnu_srs: imagine if you could just alter the code or data of any
+ suid program just because you're debugging it
+
+
+## IRC, freenode, #hurd, 2013-11-18
+
+ <gnu_srs> Hi, is the code path different for a suid program compared to run
+ as root?
+ <gnu_srs> Combined with LD_PRELOAD?
+ <teythoon> gnu_srs: afaik LD_PRELOAD is ignored by suid programs for
+ obvious security reasons
+ <gnu_srs> aha, thanks:-/
+ <braunr> gnu_srs: what's your problem with suid ?
+ <gnu_srs> I made changes to libc and tried them out with
+ LD_PRELOAD=... test_progam. It worked as any user (including root),
+ <gnu_srs> but not with suid settings. Justus explained why not.
+ <braunr> well i did too
+ <braunr> but is that all ?
+ <braunr> i mean, why did you test with suid programs in the first place ?
+ <gnu_srs> to get different euid and egid numbers
+
+ <gnu_srs> hi, anybody seen this with eglibc-2.17-96: locale: relocation
+ error: locale: symbol errno,
+ <gnu_srs> version GLIBC_PRIVATE not defined in file libc.so.0.3 with link
+ time reference
+ <teythoon> yes, I have
+ <teythoon> but afaics nothing did break, so I ignored it
+
+
+## IRC, freenode, #hurd, 2013-11-23
+
+ <gnu_srs> Finally 8-)
+ <gnu_srs> Good news: soon both SCM_CREDS _and_ SCM_RIGHTS is supported
+ jointly. RFCs will be sent soon.
+
+
+## IRC, freenode, #hurd, 2013-12-05
+
+ <gnu_srs> I have a problem with the SCM_CREDS patch and dbus. gamin and my
+ test code runs fine.
+ <gnu_srs> the problem with the dbus code is that it won't work well with
+ <gnu_srs> auth_user_authenticate in sendmsg and auth_server_authenticate in
+ recvmsg.
+ <gnu_srs> Should I try to modify the dbus code to make it work?
+ <youpi> unless you manage to prove that dbus is not following the posix
+ standard, there is no reason why you should have to modify dbus
+ <gnu_srs> I think the implementation is correct,
+ <gnu_srs> but auth_user_authenticate hangs sendmsg until
+ auth_seerver_authenticate is executed in recvmsg.
+ <gnu_srs> and dbus is not doing that, so it hangs in sendmsg writing a
+ credentials byte.
+ <gnu_srs> well the credentials byte is definitely non-posix.
+ <gnu_srs> I found a bug related to the HURD_DPORT_USE macro too:-(
+ <youpi> ah, yes, auth_user_authenticate might be synchronous indeed, let me
+ think about it
+ <gnu_srs> Nevertheless, I think it's time to publish the code so it can be
+ commented on:-D
+ <youpi> sure
+ <youpi> publish early, publish often
+
+
+# IRC, freenode, #hurd, 2014-01-17
+
+ <gnu_srs> youpi: as a start all our requested dbus changes are now
+ committed, and in Debian unstable
+ <youpi> good :)
+
+
+# IRC, freenode, #hurd, 2014-01-30
+
+ <pochu> dbus has some known problems
+ <pere> known fixes too?
+ <pochu> http://www.gnu.org/software/hurd/open_issues/dbus.html
+ <gnu_srs> pochu: Maybe that page should be updated:
+ http://lists.nongnu.org/archive/html/bug-hurd/2013-12/msg00150.html
+ <youpi> gnu_srs: well, maybe you can do it :
+ <youpi> )
diff --git a/open_issues/dbus_in_linux_kernel.mdwn b/open_issues/dbus_in_linux_kernel.mdwn
new file mode 100644
index 00000000..6f83db03
--- /dev/null
+++ b/open_issues/dbus_in_linux_kernel.mdwn
@@ -0,0 +1,164 @@
+[[!meta copyright="Copyright © 2010, 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]]."]]"""]]
+
+[[!meta title="AF_BUS, D-Bus, and the Linux kernel"]]
+
+Might be interesting to watch how this develops.
+
+[[!toc]]
+
+
+# IRC, freenode, #hurd, about 2010-08/2010-09
+
+ <neal> check this out:
+ <neal> someone is working on implementing dbus in linux
+ <neal> linux finally gets mach ipc ;-)
+ <marcusb> it's old news though, unless there is an update
+ <marcusb> and I think it was only the client?
+ <neal> youpi : someone is adding dbus ipc to the linux kernel
+ <neal> marcusb: I just heard about it.
+ <youpi> (it's crazy how this drives backward compared to a hurdish approach)
+ <youpi> what is the motivation for moving to the kernel?
+ <neal> context switch overhead
+ <azeem_> they wanna use it to talk to device drivers? :)
+ <kilobug> well, they did that with the in-kernel web server, but they
+ abandonned it later on
+ <neal> azeem: I don't think so.
+ <neal> dbus in the kernel is actually good for the Hurd as dbus IPC is
+ basically neutered Mach IPC
+ <marcusb> I don't think anybody wants to put the dbus server in the kernel
+ <neal> well, there is at least one person
+ <marcusb> maybe this is a different news from the one I read
+ <neal> Alban Crequy (albanc) is working out. He works for collabora, fwiw
+
+<http://alban.apinc.org/blog/2010/09/15/d-bus-in-the-kernel-faster/>
+
+ <marcusb> what I read was about hal etc
+ <marcusb> so that you don't need a user space daemon to glue the kernel to the
+ dbus world
+ <neal> I don't think that is what he is talking about
+ <marcusb> I can't find it anymore though. I mentioned it in this channel at
+ the time though, so it should be in the backlog
+ <marcusb> neal, yeah could very well be a separate thing
+ <marcusb> neal, dbus does have marginal support for fd passing though, and some
+ attempts on the mailing list to make "fds" an official type in the message
+ failed (as far as I could see, I didn't read the whole discussion)
+ <marcusb> so no mach ipc just yet
+ <neal> wrong
+ <neal> FD handling is in 1.4
+ <neal> type o, if I'm not mistaken
+ <marcusb> then the discussion moved on from initial rejection
+ <neal> no, 'h'
+ <marcusb> I'm out of date by two months
+ <marcusb> ok
+ <guillem> neal: AFAIR Marcel Holtmann talked about dbus in-kernel several years
+ ago, but he never ended up implementing it, or there were rumors he had
+ private "working code"
+
+ * Related Mailing List Discussion
+
+ * [\[PATCH 0/5\] RFC: Multicast and filtering features on
+ AF_UNIX](http://article.gmane.org/gmane.linux.kernel/1040481),
+ 2010-09-24
+
+
+# 2013-02
+
+[AF_BUS, D-Bus, and the Linux
+kernel](http://www.kroah.com/log/linux/af_bus.html), Greg Kroah-Hartman,
+2013-02-08.
+
+
+# kdbus
+
+
+## IRC, freenode, #hurd, 2014-01-28
+
+ <braunr> i would like to see things like dbus and zeromq use an optimized
+ microkernel transport one day
+ <teythoon> we could port kdbus >,<
+ <braunr> why not
+ <braunr> you port cgroups first
+ <teythoon> exactly
+ <braunr> :p
+
+[[systemd]].
+
+
+## IRC, freenode, #hurd, 2014-02-23
+
+In context of [[linux_as_the_kernel]], *IRC, freenode, #hurd, 2014-02-23*.
+
+ <desrt> mach seems like this really simple thing when you first explain
+ what a microkernel is
+ <braunr> and because of that, i think it's better to start the right
+ solution directly
+ <braunr> it looks simple, it's clearly not
+ <desrt> but i did a bit of looking into it... it's a bit non-trivial after
+ all :)
+ <braunr> mach ipc is over complicated and error prone
+ <braunr> it leads to unefficient communication compared to other solutions
+ such as what l4 does
+ <desrt> ya -- i hear that this is a big part of the performance hit
+ <braunr> that's why i've started x15
+ <desrt> i was also doing some reading about how it's based on mapping
+ memory segments between processes
+ <braunr> first, it was a mach clone, but since i've come to know mach
+ better, it's now a "spiritual" mach successor .. :)
+ <desrt> these are two issues that we've been dealing with at another
+ level... in the design of kdbus
+ <braunr> ah kdbus :)
+ <desrt> this is something that started with my masters thesis a long time
+ ago...
+ <braunr> ah you too
+ <desrt> first thing we did is make the serialisation format so that all
+ messages are valid and therefore never need to be checked
+ <desrt> (old dbus format requires checks at every step on the way)
+ <braunr> looks interesting
+ <desrt> then of course we cut the daemon out
+ <desrt> but some other interesting things: security is super-simple... it's
+ based enirely on endpoints
+ <desrt> either you're allowed to send messages between two processes or
+ you're not
+ <desrt> there is no checking for message types, for example
+ <braunr> yes
+ <desrt> and the other thing: memory mapping is usually bad
+ <braunr> that's what i mean when i say mach ipc is over complicated
+ <braunr> it depends
+ <desrt> the kdbus guys did some performance testing and found out that if
+ the message is less than ~512k then the cost of invalidating the TLB in
+ order to change the memory mapping is higher than the cost of just
+ copying the data
+ <braunr> yes, we know that too
+ <braunr> that's why zero copy isn't the normal way of passing small amounts
+ of data over mach either
+ <desrt> nice
+ <desrt> i got the impression in some of my reading (wikipedia, honestly)
+ that memory mapping was being done all the time
+ <braunr> well
+ <braunr> no it's not
+ <braunr> memory mapping is unfortunately a small fraction of the
+ performance overhead
+ <desrt> that's good :)
+ <braunr> that being said
+ <braunr> memory mapping can be very useful
+ <braunr> for example, it's hard for us to comply with posix requirements of
+ being able to read/write at least 2G of data in a single call
+ <braunr> weird bugs occur beyond 512M iirc
+ <braunr> you do want memory mapping for that
+ <desrt> ya... for things of this size.... you don't want to copy that
+ through a socket :)
+ <braunr> monolithic kernels have it naturally, since the kernel is mapped
+ everywhere
+ <braunr> for microkernels, it's a little more complicated
+ <braunr> and the problem gets worse on smp
+ <braunr> again, that's why i preferred starting a new kernel instead of
+ reusing linux
diff --git a/open_issues/dde.mdwn b/open_issues/dde.mdwn
new file mode 100644
index 00000000..e7083557
--- /dev/null
+++ b/open_issues/dde.mdwn
@@ -0,0 +1,661 @@
+[[!meta copyright="Copyright © 2010, 2011, 2012, 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]]."]]"""]]
+
+[[!tag open_issue_hurd open_issue_gnumach]]
+
+[[General Information|/dde]].
+
+Still waiting for interface finalization and proper integration.
+
+[[!toc]]
+
+See [[user-space_device_drivers]] for generic discussion related to user-space
+device drivers.
+
+
+# Disk Drivers
+
+Not yet supported.
+
+The plan is to use [[libstore_parted]] for accessing partitions.
+
+
+# Upstream Status
+
+
+## IRC, freenode, #hurd, 2012-02-08
+
+After the microkernel devroom at [[community/meetings/FOSDEM_2012]]:
+
+ <antrik> there was quite some talk about DDE. I learnt that there are newer
+ versions in Genode and in Minix (as opposed to the DROPS one we are
+ using)
+ <antrik> but apparently none of the guys involved is interested in creating
+ a proper upstream project with central repository and communication
+ channels :-(
+ <antrik> the original DDE creator was also there, but said he isn't working
+ on it anymore
+ <tschwinge> OK, and the other two projects basically have their own forks.
+ <tschwinge> Or are they actively cooperating?
+ <tschwinge> (If you know about it.)
+ <antrik> well, Genode is also part of the Dresden L4 group; but apart from
+ that, I'd rather call it a fork...
+ <antrik> hm... actually, I'm not sure anymore whether the guy I talked to
+ was from Genode or Nova...
+ <antrik> (both from the Dresdem L4 group)
+
+
+### IRC, freenode, #hurd, 2012-08-12
+
+ <antrik>
+ http://genode.org/documentation/release-notes/12.05#Re-approaching_the_Linux_device-driver_environment
+ <antrik> I wonder whether the very detailed explanation was prompted by our
+ DDE discussions at FOSDEM...
+ <pinotree> antrik: one could think about approaching them to develop the
+ common dde libs + dde_linux together
+ <antrik> pinotree: that's what I did at FOSDEM -- they weren't interested
+ <pinotree> antrik: this year's one? why weren't they?
+ <pinotree> maybe at that time dde was not integrated properly yet (netdde
+ is just few months "old")
+ <braunr> do you really consider it integrated properly ?
+ <pinotree> no, but a bit better than last year
+ <antrik> I don't see what our integration has to do with anything...
+ <antrik> they just prefer hacking thing ad-hoc than having some central
+ usptream
+ <pinotree> the helenos people?
+ <antrik> err... how did helenos come into the picture?...
+ <antrik> we are talking about genode
+ <pinotree> sorry, confused wrong microkernel OS
+ <antrik> actually, I don't remember exactly who said what; there were
+ people from genode there and from one or more other DDE projects... but
+ none of them seemed interested in a common DDE
+ <antrik> err... one or two other L4 projects
+
+
+## IRC, freenode, #hurd, 2012-02-19
+
+ <youpi> antrik: do we know exactly which DDE version Zheng Da took as a
+ base ?
+ <youpi> (so as to be able to merge new changes easily)
+ <antrik> youpi: not sure... but from what I gathered at FOSDEM, the version
+ he based on (from DROPS) is not really actively developed right now; if
+ we want to go for newer versions, we probably have to look at other
+ projects (like Genode or Nova or Minix)
+ <youpi> there's no central project for dde ?
+ <youpi> that sucks
+ <antrik> no... and nobody seemed interested in having one :-(
+ <youpi> pff
+ <antrik> which makes me seriously question the original decision to build
+ on DDE...
+ <braunr> ..
+ <antrik> if we have to basically maintain it ourselfs anyways, we could
+ just as well have gone with custom glue
+ <youpi> well, the advantage of DDE is that it already exists now
+ <antrik> on the positive side, one of the projcets (not sure which)
+ apparently have both USB and SATA working with some variant of DDE
+
+
+### IRC, freenode, #hurd, 2012-11-03
+
+ <mcsim> DrChaos: there is DDEUSB framework for L4. You could port it, if
+ you want. It uses Linux 2.6.26 usb subsystem.
+
+
+## IRC, freenode, #hurd, 2013-02-15
+
+After the microkernel devroom at [[community/meetings/FOSDEM_2013]].
+
+ <pinotree> youpi: speaking of dde, was there any will among other
+ microkernel os developers to eventually develop one single dde (with
+ every team handling the custom glue of the own kernel)?
+ <youpi> well, there is still upstream dde actually
+ <youpi> in dresden
+ <youpi> nothing was really decided or anything (it was a round table, not a
+ workgroup)
+ <youpi> but conversation converged into sharing the DDE maintenance, yes
+ <youpi> and dresden would be the logical central place
+ <youpi> pb is that they don't have the habit of being very open
+ <youpi> http://svn.tudos.org/repos/oc/tudos/trunk/l4/pkg/dde has a recent
+ enough version
+ <youpi> which macsim confirmed having all the latest commits from the
+ internal repository
+ <pinotree> i see
+ <youpi> so it seems a viable solution on the medium term
+ <youpi> the long term might need a real visible open source project
+ <youpi> but we should probably still keep basing on dresden work
+ <youpi> (better take work being done anywhere)
+ <pinotree> well, if the upstream is not really open, microkernel teams
+ could just fork it and all work on it
+ <youpi> that's what I mean
+ <pinotree> should still be a win than everybody maintaining their own dde
+ <youpi> sure
+ <pinotree> ah yes, i was writing and i'm slow at it :)
+ <youpi> but at least we can try to work with dresden
+ <youpi> see how open they could become by just asking :)
+ <pinotree> right
+
+
+# IRC, OFTC, #debian-hurd, 2012-02-15
+
+ <pinotree> i have no idea how the dde system works
+ <youpi> gnumach patch to provide access to physical memory and interrupts
+ <youpi> then userland accesses i/o ports by hand to drive things
+ <youpi> but that assumes that no kernel driver is interfering
+ <youpi> so one has to disable kernel drivers
+ <pinotree> how are dde drivers used? can they be loaded on their own
+ automatically, or you have to settrans yourself to setup a device?
+ <youpi> there's no autoloader for now
+ <youpi> we'd need a bus arbitrer that'd do autoprobing
+
+[[PCI_arbiter]].
+
+ <pinotree> i see
+ <pinotree> (you see i'm not really that low level, so pardon the flood of
+ posssibly-noobish questions ;) )
+ <youpi> I haven't set it up yet, but IIRC you need to specify which driver
+ to be used
+ <youpi> well, I mostly have the same questions actually :)
+ <youpi> I just have some guesswork here :)
+ <pinotree> i wonder whether the following could be feasible:
+ <youpi> I'm wondering how we'll manage to make it work in d-i
+ <pinotree> a) you create a package which would b-d on linux-source, build a
+ selection of (network only for now) drivers and install them in
+ /hurd/dde/
+ <youpi> probably through a choice at the boot menu
+ <youpi> I wouldn't dare depending on linux-source
+ <youpi> dde is usually not up-to-date
+ <pinotree> b) add a small utility over the actual fsys_settrans() which
+ would pick the driver from /hurd/dde/
+ <pinotree> ... so you could do `set-dde-driver b43 <device>` (or something
+ like that)
+ <youpi> we can provide something like b) yes
+ <youpi> although documenting the settrans should be fine enough ;)
+ <pinotree> the a) would help/ease with the fact that you need to compile on
+ your own the drivers
+ <pinotree> otherwise we would need to create a new linux-dde-sources-X.Y.Z
+ only with the sources of the drivers we want from linux X.Y.Z
+ <pinotree> (or hurd-dde-linux-X.Y.Z)
+ <CIA-4> samuel.thibault * raccdec3 gnumach/debian/ (changelog
+ patches/70_dde.patch patches/series):
+ <CIA-4> Add DDE experimental support
+ <CIA-4> * debian/patches/70_dde.patch: Add experimental support for irq
+ passing and
+ <CIA-4> physical memory allocation for DDE. Also adds nonetdev boot
+ parameter to
+ <CIA-4> disable network device drivers.
+ <youpi> ok, boots fine with the additional nonetdev option
+ <youpi> now I need to try that dde hurd branch :)
+ <CIA-4> samuel.thibault * rf8b9426 gnumach/debian/patches/70_dde.patch: Add
+ experimental.defs to gnuamch-dev
+
+
+# IRC, freenode, #hurd, 2012-02-19
+
+ * youpi got dde almost working
+ <youpi> it's able to send packets, but apparently not receive them
+ <youpi> (e1000)
+ <youpi> ok, rtl8139 works
+ <youpi> antrik: the wiki instructions are correct
+ <youpi> with e1000 I haven't investigated
+ <antrik> (Archhurd guys also reported problems with e1000 IIRC... the one I
+ built a while back works fine though on my T40p with real e1000 NIC)
+ <antrik> maybe I should try with current versions... something might got
+ broken by later changes :-(
+ <youpi> at least testing could tell the changeset which breaks it
+ <youpi> Mmm, it's very odd
+ <youpi> with the debian package, pfinet's call to device_set_filter returns
+ D_INVALID_OPERATION
+ <youpi> and indeed devnode.c returns that
+ <youpi> ah but it's libmachdev which is supposed to answer here
+ <antrik> youpi: so, regarding the failing device_set_filter... I guess you
+ are using some wrong combination of gnumach and pfinet
+ <youpi> no it's actually that my pfinet was not using bpf
+ <youpi> I've now fixed it
+ <antrik> the DDE drivers rely on zhengda's modified pfinet, which uses
+ devnode, but also switched to using proper BPF filters. so you also need
+ his BPF additions/fixes in gnumach
+ <antrik> OK
+ <youpi> that's the latter
+ <youpi> I had already fixed the devnode part
+ <youpi> but hadn't seen that the filter was different
+ <antrik> err... did I say gnumach? that of course doesn't come into play
+ here
+ <antrik> so yes, you just need a pfinet using BPF
+ <youpi> libmachdev does ;)
+ <antrik> I'm just using pfinet from zhengda's DDE branch... I think devnode
+ and BPF are the only modifications
+ <youpi> there's also a libpcap modification in the incubator
+ <youpi> probably for tcpdump etc.
+ <antrik> libpcap is used by the modified pfinet to compile the filter rule
+ <youpi> why does pfinet need to compile the rule ?
+ <youpi> it's libbpf which is used in the dde driver
+ <antrik> it doesn't strictly need to... but I guess zhengda considered it
+ more elegant to put the source rule in pfinet on compile it live, rather
+ than the compiled blob
+ <antrik> I probably discussed this with him myself a few years back... but
+ my memory on this is rather hazy ;-)
+ <antrik> err... and compile it live
+ <youpi> ah, right, it's only used when asking pfinet to change its filter
+ <youpi> but it does not need it for the default filter
+ <youpi> which is hardcoded
+ <antrik> I see
+ <antrik> when would pfinet change its filter?
+ * youpi now completely converting his hurd box to debian packages with dde
+ support
+ <youpi> on SIOCSIFADDR apparently
+ <youpi> to set "arp or (ip host %s)",
+ <antrik> well, that sounds like the default filter...
+ <youpi> the default filter does not choose an IP
+ <antrik> oh, right... pfinet has to readjust the filter when setting the IP
+ <youpi> arg we lack support for kernel options for gnumach in update-grub
+ <antrik> again, I have a vague recollection of discussing this
+ * youpi crosses fingers
+ <youpi> yay, works
+ <antrik> so we *do* need libpcap in pfinet to set proper rules... though I
+ guess it can also work with a static catchall rule (like it did before
+ zhengda's changes), only less efficient
+ <youpi> well in the past we were already catching everything anyway, so at
+ least it's not a regression :)
+ <antrik> right
+
+
+# [[PCI_Arbiter]]
+
+## IRC, freenode, #hurd, 2012-02-21
+
+ <youpi> since all drivers need is interrupts, io ports and iomem
+ <youpi> the latter was already available through /dev/mem
+ <youpi> io ports through the i386 rpcs
+ <youpi> the changes provide both interrupts, and physical-contiguous
+ allocation
+ <youpi> it should be way enough
+ <braunr> youpi: ok
+ <braunr> youpi: thanks for the details :)
+ <antrik> braunr: this was mentioned in the context of the interrupt
+ forwarding interface... the original one implemented by zhengda isn't
+ suitable for a PCI server; but the ones proposed by youpi and tschwinge
+ would work
+ <antrik> same for the physical memory interface: the current implementation
+ doesn't allow delegation; but I already said that it's wrong
+
+
+# IRC, freenode, #hurd, 2012-02-20
+
+ <youpi> I was a bit wary of including the ton of dde headers in hurd-dev
+ <youpi> maybe adding another package for that
+ <youpi> but that would have delayed introducing the dde binaries
+ <youpi> probably we can do that for next upload
+ <pinotree> i can try to work on it, if is feasible (ie if the dde drivers
+ can currently be built from outside the hurd source tree)
+ <youpi> it should be, it's a matter of pointing its makefile to a place
+ where the make scripts and include headers are
+ <youpi> (and the libraries)
+ <pinotree> ok
+ <antrik> youpi: you mean DDEKit headers?
+ <antrik> pinotree: actually it doesn't matter where the dde-ified Linux
+ drivers are built -- libdde_linux26 and the actual drivers use a
+ completetly different build system anyways
+ <antrik> in fact we concluded at some point that they should live in a
+ separate repository -- but that change never happened
+ <antrik> only the base stuff (ddekit, libmachdev etc.) belong in the Hurd
+ source tree
+ <youpi> antrik: yes
+ <youpi> antrik: err, not really completely different
+ <youpi> the actual drivers' Makefile include the libdde_linux26 mk files
+ <youpi> the build itself is separate, though
+ <antrik> youpi: yes, I mean both libdde_linux26 and the drivers use a build
+ system that is completely distinct from the Hurd one
+ <youpi> ah, yes
+ <youpi> libdde_linux26 should however be shipped in the system
+ <antrik> ideally libdde_linux26 and all the drivers should be built in one
+ go I'd say...
+ <youpi> it should be easily feasible to also have a separate driver too
+ <youpi> e.g. to quickly try a 2.6 driver
+ <antrik> youpi: I'm not sure about that. it's not even dynamically linked
+ IIRC?...
+ <youpi> with scripts to build it
+ <youpi> it's not
+ <youpi> but that doesn't mean it can't be separate
+ <youpi> .a files are usually shipped in -dev packages
+ <antrik> youpi: ideally we should try to come with a build system that
+ reuses the original Linux makefile snippets to build all the drivers
+ automatically without any manual per-driver work
+ <youpi> there's usually no modification of the drivers themselves?
+ <youpi> but yeah
+ <youpi> "ideally", when somebody takes the time to do it
+ <antrik> unfortunately, it's necessary to include one particular
+ Hurd/DDE-specific header file in each driver :-(
+ <youpi> can't it be done through gcc's -include option?
+ <antrik> zhengda didn't find a way to avoid this... though I still hope
+ that it must be possible somehow
+ <antrik> I think the problem is that it has to be included *after* the
+ other Linux headers. don't remember the details though
+ <youpi> uh
+ <youpi> well, a good script can add a line after the last occurrence of
+ #include
+ <antrik> yeah... rather hacky, but might work
+ <youpi> even with a bit of grep, tail, cut, and sed it should work :)
+ <antrik> note that this is Hurd-specific; the L4 guys didn't need that
+ <youpi> what is it?
+ <antrik> don't remember off-hand
+
+
+# IRC, freenode, #hurd, 2012-02-22
+
+ <youpi> antrik: AIUI, it should be possible to include all network drivers
+ in just one binary?
+ <youpi> that'd permit to use it in d-i
+ <youpi> and completely replace the mach drivers
+ <youpi> we just need to make sure to include at least what the mach drivers
+ cover
+ <youpi> (all DDE network drivers, I mean)
+ <youpi> of course that doesn't hinder from people to carefully separate
+ drivers in several binaries if they wish
+ <youpi> antrik: it does link at least, I'll give a try later
+ <youpi> yes it works!
+ <youpi> that looks like a plan
+ <youpi> throw all network drivers in a /hurd/dde_net
+ <youpi> settrans it on /dev/dde_net, and settrans devnode on /dev/eth[0-9]
+ <youpi> I'm also uploading a version of hurd which includes headers &
+ libraries, so you just need a make in dde_{e100,e1000,etc,net}
+ <youpi> (uploading it with the dde driver itself :) )
+ <youpi> btw, a nice thing is that we don't really care that all drivers are
+ stuffed into a single binary, since it's a normal process only the useful
+ pages are mapped and actually take memory :)
+ <Tekk_> is that really a nice thing though? compared to other systems I
+ mean
+ <Tekk_> I know on linux it only loads the modules I need, for example. It's
+ definitely a step up for hurd though :D
+ <youpi> that's actually precisely what I mean
+ <youpi> you don't need to load only the modules you need
+ <youpi> you just load them all
+ <youpi> and paging eliminates automatically what's not useful
+ <youpi> even parts of the driver that your device will not need
+ <Tekk_> ooh
+ <Tekk_> awesome
+ <youpi> (actually, it's not even loaded, but the pci tables of the drivers
+ are loaded, then paged out)
+
+
+# IRC, freenode, #hurd, 2012-02-24
+
+ <youpi> antrik_: about the #include <ddekit/timer.h>, I see the issue, it's
+ about jiffies
+ <youpi> it wouldn't be a very good thing to have a jiffies variable which
+ we'd have to update 100times per second
+ <youpi> so ZhengDa preferred to make jiffies a macro which calls a function
+ which reads the mapped time
+
+[[Mapped-time_interface|microkernel/mach/gnumach/interface/device/time]].
+
+ <youpi> however, that break any use of the work "jiffies", e.g. structure
+ members & such
+ <youpi> actually it's not only after headers that the #include has to be
+ done, but after any code what uses the word "jiffies" for something else
+ than the variable
+ <youpi> pb is: it has to be done *before* any code that uses the word
+ "jiffies" for the variable, e.g. inline functions in headers
+ <youpi> in l4dde, there's already the jiffies variable so it's not a
+ problem
+
+
+# IRC, OFTC, #debian-hurd, 2012-02-27
+
+ <tschwinge> I plan to do some light performance testing w.r.t. DDE
+ Ethernet. That is DDE vs. Mach, etc.
+ <youpi> that'd be good, indeed
+ <youpi> I'm getting 4MiB/s with dde
+ <youpi> I don't remember with mach
+ <tschwinge> Yes. It just shouldn't regress too much.
+ <tschwinge> Aha, OK.
+
+
+## IRC, freenode, #hurd, 2012-02-27
+
+ <youpi> tschwinge: nttcp tells me ~80Mbps for mach-rtl8139, ~72Mbps for
+ dde-rtl8139, ~72Mbps for dde-e1000
+ <youpi> civodul: ↑ btw
+ <ArneBab> youpi: so the dde network device is not much slower than the
+ kernel-one?
+ <civodul> youpi: yes, looks good
+ <ArneBab> rather almost the same speed
+ <youpi> apparently
+ <ArneBab> that’s quite a deal.
+ <ArneBab> what speed should it have as maximum?
+ <ArneBab> (means: does the mach version get out all that’s possible?)
+ <ArneBab> differently put: What speed would GNU/Linux get?
+ <youpi> I'm checking that right now
+ <ArneBab> cool!
+ <ArneBab> we need those numbers for the moth after the next
+ <youpi> Mmm, I'm not sure you really want the linux number :)
+ <youpi> 1.6Gbps :)
+ <ArneBab> oh…
+ <youpi> let me check with udp rather than tcp
+ <ArneBab> so the Hurd is a “tiny bit” worse at using the network…
+ <youpi> it might simply be an issue with tcp tuning in pfinet
+ <ArneBab> hm, yes
+ <ArneBab> tcp is not that cheap
+ <ArneBab> and has some pretty advanced stuff for getting to high speeds
+ <youpi> well, I'm not thinking about being cheap
+ <youpi> but using more recent tuning
+ <youpi> that does not believe only 1Mbps network cards exist :)
+ <ArneBab> like adaptive windows and such?
+ <ArneBab> :)
+ <youpi> yes
+ * ArneBab remembers that TCP was invented when the connections went over
+ phone lines - by audio :)
+ <youpi> yep
+ <ArneBab> what’s the system load while doing the test?
+ <youpi> yes, udp seems not so bad
+ <ArneBab> ah, cool!
+ <youpi> it's very variable (300-3000Mbps), but like on linux
+ <ArneBab> that pushing it into user space has so low cost is pretty nice.
+ * ArneBab thinks that that’s a point where Hurd pays off
+ <youpi> that's actually what AST said to fosdem
+ <youpi> he doesn't care about putting an RPC for each and every port i/o
+ <youpi> because hardware is slow anyway
+ <ArneBab> jupp
+ <ArneBab> but it is important to see that in real life
+
+
+# IRC, freenode, #hurd, 2012-04-01
+
+ <youpi> antrik: I wonder whether you could actually not route the IRQs to a
+ non-zero ring, AIUI you can in the x86 IDT table
+ <antrik> youpi: you mean having a userspace server for each (non-timer)
+ interrupt?
+ <antrik> youpi: how would a userspace IRQ handler interact with the
+ scheduler?
+ <youpi> antrik: it doesn't necessarily have to
+ <youpi> provided that it's trusted
+ <antrik> youpi: how would you do CPU time accounting if there is no
+ interaction with the scheduler?...
+ <youpi> antrik: you don't necessarily want to care about it
+ <antrik> youpi: well, that would mean that all drivers handling interrupts
+ would have to be trusted to not use more than a very small part of CPU
+ time...
+ <youpi> yes
+ <youpi> which is usually needed for interrupt handlers anyway
+ <antrik> youpi: nah, the bottom handler only has to do very basic stuff;
+ afterwards, we can pass off to "normal" driver processes, scheduled just
+ like other processes... but that requires some interaction between the
+ IRQ handler and the scheduler I think
+ <youpi> the IRQ handler can wake up a thread, yes
+ <youpi> no need for anything special there
+ <antrik> so the userspace IRQ server would just decide what process to wake
+ up, and then call the scheduler to do a normal task switch? I guess
+ that's possible; but I'm not sure it would buy much...
+ <youpi> it would permit userland to quickly react to the IRQ
+ <youpi> such as acknowledge it to the hardware etc.
+ <antrik> yeah, but my point is that I don't see much benefit in having this
+ part of the code isolated in a userspace process... it has to be trusted
+ anyways, and it's pretty trivial too
+ <youpi> I never said it was a good idea
+
+
+# IRC, freenode, #hurd, 2012-04-06
+
+ <braunr> oh i forgot about my work on pcap
+ <braunr> is devnode (or devopen or whatever) in the upstream repository now
+ ?
+ <antrik> can't say for sure, but I'd be surprised... don't remember seeing
+ any movement in that regard :-(
+ <braunr> wasn't it needed for dde ?
+ <antrik> hm... good point
+
+
+## IRC, freenode, #hurd, 2013-09-20
+
+ <braunr> i should take some time to integrate my pcap changes into the
+ libpcap debian package at least
+ <pinotree> braunr: if upstream is active, i'd say to go there directly
+ <braunr> the problem with that approach is that netdde is still not part of
+ our upstream code
+ <pinotree> don't understand the relation
+ <braunr> i don't want to send the pcap guys code for an interface that is
+ still not considered upstream ...
+
+
+# IRC, freenode, #hurd, 2012-08-14
+
+ <braunr> it's amazing how much code just gets reimplemented needlessly ...
+ <braunr> libddekit has its own mutex, condition, semaphore etc.. objects
+ <braunr> with the *exact* same comment about the dequeueing-on-timeout
+ problem found in libpthread
+ <braunr> *sigh*
+
+
+## IRC, freenode, #hurd, 2012-08-18
+
+ <braunr> hum, leaks and potential deadlocks in libddekit/thread.c :/
+
+
+## IRC, freenode, #hurd, 2012-08-18
+
+ <braunr> nice, dde relies on a race to start ..
+
+
+## IRC, freenode, #hurd, 2012-08-21
+
+In context of [[libpthread]].
+
+ <braunr> hm, i thought my pthreads patches introduced a deadlock, but
+ actually this one is present in the current upstream/debian code :/
+ <braunr> (the deadlock occurs when receiving data fast with sftp)
+ <braunr> either in netdde or pfinet
+
+
+## IRC, freenode, #hurd, 2013-02-28
+
+ <braunr> (which needs the same kinds of fixes that libpthread got)
+ <braunr> actually i'm not sure why he didn't simply reuse the pthread
+ functions :/
+ <youpi> which kind of fixes?
+ <youpi> cancellation?
+ <braunr> timeouts
+ <braunr> cancellation too but that's less an issue
+ <youpi> I'm not sure it really needs timeout work
+ <youpi> on what RPC?
+ <youpi> pfinet is just using the mach interface
+ <braunr> i don't know but it clearly copies some of the previous pthread
+ code from pthread_cond_timedwait
+ <braunr> see libddekit/thread.c:_sem_timedwait_internal
+ <youpi> I recognize the comment indeed :)
+ <youpi> I guess he thought he might need some particular semantic that
+ libpthread may not provide
+ <braunr> also, now that i think about it, he couldn't have used libpthread,
+ could he ?
+ <braunr> and there was no condition_timedwait in cthreads
+ <braunr> there is a deadlock in netdde
+ <braunr> it occurs sometimes, at high network speeds
+ <braunr> (well high, 4 MiB/s or more)
+
+
+## IRC, freenode, #hurd, 2013-11-20
+
+ <braunr> for example, netdde needs more reviewing and polishing
+ <braunr> it is known to deadlock sometimes
+ <teythoon> what deadlocks ?
+ <braunr> i'm not sure
+ <teythoon> ah, netdde
+ <teythoon> right
+ <braunr> yes
+ <teythoon> I'm seeing that to on one of my vms
+ <teythoon> nasty one
+ <braunr> i know something is wrong with the condition_wait_timeout function
+ for example
+ <teythoon> breaks sysvinit shutdown
+ <braunr> because it was taken without modification from libpthread
+ <braunr> it might be that, or something else
+ <teythoon> well, dhclient hangs releasing the lease
+ <braunr> that's still on my todo list
+ <teythoon> so I'm pretty sure it's related
+ <braunr> hm
+ <braunr> maybe
+ <braunr> :/
+
+
+## IRC, freenode, #hurd, 2014-02-11
+
+ <braunr> teythoon: looks like a netdde/pfinet freeze/deadlock
+ <braunr> yes a netdde deadlock
+ <braunr> i really have to fix that too one day :(
+ <teythoon> hehe :)
+ <braunr> the netdde locking privimites are copies of the "old" pthread
+ ones, instead of reusing pthread
+ <braunr> primitives*
+
+
+## IRC, freenode, #hurd, 2014-03-08
+
+ <gg0> what to do if network freezes?
+ <teythoon> gg0: depends on what caused the freeze
+ <teythoon> gg0: you could try to kill the netdde process
+ <gg0> it's just apt-get'ing, download phase
+ <braunr> yess kill netdde
+ <braunr> there are known deadlocks in netdde
+
+
+# IRC, freenode, #hurd, 2012-08-18
+
+ <braunr> hm looks like if netdde crashes, the kernel doesn't handle it
+ cleanly, and we can't attach another netdde instance
+
+[[!message-id "877gu8klq3.fsf@kepler.schwinge.homeip.net"]]
+
+
+# DDE for Filesystems
+
+## IRC, freenode, #hurd, 2012-10-07
+
+ * pinotree wonders whether the dde layer could aldo theorically support
+ also file systems
+ <antrik> pinotree: yeah, I also brought up the idea of creating a DDE
+ extension or DDE-like wrapper for Linux filesystems a while back... don't
+ know enough about it though to decide whether it's doable
+ <antrik> OTOH, I'm not sure it would be worthwhile. we still should
+ probably have a native (not GPLv2-only) implementation for the main FS at
+ least; so the wrapper would only be for accessing external
+ partitions/media...
+
+
+## IRC, freenode, #hurd, 2013-12-03
+
+ <gg0> how about porting linux block device layer via dde as mcsim wanted to
+ do? then all linux filesystems could be brought in, right?
+ <braunr> gg0: that should be done, but we need to correctly deal with
+ multiple pci devices in userspace and arbitration
+ <kilobug> wouldn't adding support to passive translator into Linux
+ filesystems be quite some work ? IIRC ext2fs needs a special "owner =
+ hurd" mode to handle them
+
+
+# [[virtio]]
diff --git a/open_issues/debian_cross_toolchain.mdwn b/open_issues/debian_cross_toolchain.mdwn
new file mode 100644
index 00000000..e0665466
--- /dev/null
+++ b/open_issues/debian_cross_toolchain.mdwn
@@ -0,0 +1,15 @@
+[[!meta copyright="Copyright © 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]]
+
+Have a look at the Debian *Cross Toolchain* project,
+<https://alioth.debian.org/projects/crosstoolchain/>,
+<http://wiki.debian.org/ToolChain/Cross>.
diff --git a/open_issues/debootstrap.mdwn b/open_issues/debootstrap.mdwn
new file mode 100644
index 00000000..8e6c4900
--- /dev/null
+++ b/open_issues/debootstrap.mdwn
@@ -0,0 +1,24 @@
+[[!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]]."]]"""]]
+
+\#hurd, freenode, 2010
+
+ <azeem_> you know, you would really help the Hurd if you tried debootstrap instead
+ <tschwinge> Oh? Does that have everying in place by now?
+ <azeem_> applying the patch in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498731#25
+ <azeem_> they are waiting for feedbacl
+ <azeem_> feedback*
+
+\#hurd, freenode, June (?) 2010
+
+ <azeem_> jd823592: if you want to use debootstrap, you should apply a patch
+ <azeem_> and test
+ <azeem_> http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=25;filename=debootstrap_hurd.patch;att=1;bug=498731
+ <azeem_> we desperately need somebody to test the patch
diff --git a/open_issues/debugging.mdwn b/open_issues/debugging.mdwn
new file mode 100644
index 00000000..107acbf6
--- /dev/null
+++ b/open_issues/debugging.mdwn
@@ -0,0 +1,56 @@
+[[!meta copyright="Copyright © 2010, 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]]."]]"""]]
+
+
+# Existing
+
+We have debugging infrastructure. For example:
+
+ * [[GDB]]
+
+ * [[GNU Mach debugging|microkernel/mach/gnumach/debugging]]
+
+ * [[GNU Hurd debugging|hurd/debugging]], including
+ [[hurd/debugging/rpctrace]], and more.
+
+
+# To Do
+
+ * [[glibc]]'s sotruss
+
+ * [[ltrace]]
+
+ * [[latrace]]
+
+ * [[profiling]]
+
+ * *Checkpoint/restart allows the state of a set of processes to be saved to
+ persistent storage, then restarted at some future time* -- quoting from
+ Jonathan Corbet's [2010 Linux Kernel Summit
+ report](http://lwn.net/Articles/412749/).
+
+ This is surely a very useful facility to have for reproducing failures, for
+ example. But on the other hand it's questionable how it can help with
+ debugging failures in [[GNU Hurd server|hurd/translator]]s' interactions,
+ as their state is typically spread between several processes.
+
+ Continues: <http://lwn.net/Articles/414264/>, which introduces
+ <http://dmtcp.sourceforge.net/>.
+
+ * [[crash_server}}, [[GDB_gcore]],
+ <http://code.google.com/p/google-coredumper/>
+
+ * [[community/gsoc/project_ideas/libdiskfs_locking]]
+
+ * <http://lwn.net/Articles/415728/>, or <http://lwn.net/Articles/415471/> --
+ just two examples; there's a lot of such stuff for Linux.
+
+ * [[debugging_gnumach_startup_QEMU_GDB]]
diff --git a/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn b/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn
new file mode 100644
index 00000000..68a04bfb
--- /dev/null
+++ b/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn
@@ -0,0 +1,165 @@
+[[!meta copyright="Copyright © 2010, 2011, 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]]."]]"""]]
+
+[[!meta title="Debugging GNU Mach's startup in QEMU with GDB"]]
+
+[[!tag open_issue_gdb open_issue_gnumach]]
+
+[[!toc]]
+
+
+# Memory Map
+
+## IRC, freenode, #hurd, 2010-06 (?)
+
+ <jkoenig> is there a way to get gdb to map addresses as required when
+ debugging mach with qemu ?
+ <jkoenig> I can examine the data if I manually map the addresses th
+ 0xc0000000 but maybe there's an easier way...
+ <youpi> jkoenig: I haven't found a way
+ <youpi> I'm mostly using the internal kdb
+
+
+## IRC, freenode, #hurd, 2011-07-14
+
+ <mcsim> Hello. I have problem with debugging gnumach. I set 2 brakepoints
+ in file i386/i386at/model_dep.c on functions gdt_init and idt_init. Then
+ I start qemu with patched gnumach kernel and stop at gdt_init. When I
+ enter command "continue" in gdb, qemu hangs. But when I go step by step,
+ using command "next", I freely reach idt_init. What can cause this
+ problem?
+ <braunr> hm
+ <braunr> not sure
+ <braunr> let me try
+ <braunr> mcsim: works for me :/
+ <mcsim> it works without my patch, but with it qemu hangs
+ <braunr> oh, i thought it worked when not using continue
+ <mcsim> with my patch I can reach idt_init only using next
+ <mcsim> and without all works fine
+ <braunr> mcsim: are you sure you correctly built it with debugging symbols
+ ?
+ <mcsim> I've written in /etc/dpkg/buildflags.conf SET CFLAGS -g3 -O0
+ <braunr> hm
+ <braunr> i have internal kvm errors actually
+ <braunr> mcsim: do you use kvm ?
+ <braunr> mcsim: and why break on those functions ?
+ <braunr> i'm not sure the address space is already fine at this point
+ <mcsim> no. I don't have hardware virtualisation support.
+ <braunr> hm actually, you won't be able to use gdb
+ <braunr> i just remembered how gnumach is linked and mapped :/
+ <braunr> the addresses in the elf image are low addresses, matching the
+ image as it is loaded by the boot loader
+ <mcsim> I was wondering why qemu hangs.
+ <braunr> then the kernel uses segmentation to map itself at 2 (or 3
+ previously) GiB
+ <braunr> well, if the addresses are wrong, your breakpoints are wrong
+ <braunr> i even wonder how it can work when stepping
+ <braunr> i don't have the issue with x15 because of its linker script
+ <mcsim> Are there any ways of such debugging without qemu?
+ <braunr> i don't think so
+ <braunr> as antrik told you, the in kernel debugger needs many services
+ running before being usable
+ <braunr> you'll have to use printf, and there may be steps during bootstrap
+ when even that isn't available
+ <mcsim> So I need computer with hardware virtualisation?
+ <braunr> well, of course stepping works, since the breakpoints are relative
+ <braunr> no
+ <braunr> kvm has nothing to do with the problem
+ <braunr> it's just that the problem appears differently with kvm enabled
+ <mcsim> ok. thank you.
+ <braunr> good luck
+ <antrik> braunr: would it be hard to "fix" gnumach to avoid the
+ segmentation magic?...
+ <braunr> antrik: because of the linux drivers, it may
+ <antrik> or alternatively, implement something in GDB to deal with that?...
+ <braunr> antrik: i didn't study that part enough to know for sure
+ <antrik> uhm... why would the Linux drivers depend on that? does Linux also
+ do such magic?...
+ <braunr> well it should simply be a matter of shifting the address by a
+ fixed offset
+ <braunr> antrik: linux drivers rely on physical memory being allocated
+ through kmalloc
+ <braunr> so there must be a direct mapping between virtual kernel memory
+ and physical memory
+ <braunr> they don't specifically need that segmentation settings
+ <braunr> so if you remove the offset implemented through segmentation, you
+ have to replace it with page mapping
+ <braunr> and i don't know how much needs to be done for that
+ <braunr> you also need to link the kernel differently
+ <antrik> hm, OK
+ <antrik> so adding GDB support for the offset would probably be easier...
+ <braunr> yes
+ <braunr> but using the offset must only be done once segmentation is set up
+ <braunr> so you must break after gdt_init
+ <braunr> not on it
+ <braunr> mcsim: why do you break on these functions btw ?
+ <mcsim> I just wanted to find out why qemu hangs
+ <braunr> yes but why those ?
+ <mcsim> I found out that before gdt_init all workes fine, but after qemu
+ hangs. So idt_init is just the next function
+ <braunr> ok
+ <braunr> and does your patch change something to how segmentation is
+ initialized ?
+ <mcsim> now
+ <mcsim> no
+ <braunr> try to build it with the regular cflags
+ <braunr> i don't know if gnumach can work with -O0
+ <mcsim> I've tried. But all the same
+ <mcsim> Regular are -g -O2
+ <braunr> can you make your patch available ?
+ <mcsim> yes
+ <mcsim> it is available in gnumach repository at savannah
+ <mcsim> tree mplaneta/libbraunr/master
+ <antrik> well, if the segmentation stuff is the thing GDB has problems
+ with, I don't see how it can work without your patch...
+ <braunr> without ?
+ <antrik> well, the patch shouldn't affect the segmentation... so I don't
+ see how it can make a difference
+ <braunr> he said qemu hanged
+ <braunr> so let's not introduce gdb yet
+ <braunr> qemu can hang for other reasons
+ <antrik> oh, right, without GDB...
+ <antrik> though if that's what he meant, his statement was very misleading
+ at least
+
+
+# <a name="multiboot">Multiboot</a>
+
+See also [[hurd/running/qemu#multiboot]].
+
+
+## IRC, freenode, #hurd, 2014-02-24
+
+ <congzhang> hi, will grub load mach kernel to fix address? and which
+ address?
+ <congzhang> I want to use qemu gdb support to debug mach
+ <congzhang> need add-symble-file to right address
+ <youpi> congzhang: see objdump gnumach
+ <youpi> grub simply follows what's provided by the ELF format of the ELF
+ file
+ <nalaginrut> I think it's default value of _start in ELF, right?
+ <nalaginrut> hmm...the actual entry point should plus the size of
+ multi_boot header, at least 0xc...
+ <congzhang> youpi: I try that, but not works
+ <congzhang> I start qemu with -s
+ <congzhang> the /bin/console was very easy to cause black death, and I want
+ to use gdb to check whether the mach is death
+ <congzhang> I will try again later
+ <congzhang> Anyone know some tutorial to debug mach with qemu?
+ <nalaginrut> for better debug, I suggest bochs
+ <nalaginrut> although it's slower
+ <congzhang> nalaginrut: maybe it's my problem, I did not do the right thing
+ <congzhang> qemu with kvm was great.
+ <nalaginrut> qemu with kvm is cool to run, but not so cool for debug kernel
+ <nalaginrut> anyway, it's personal taste
+ <nalaginrut> you may use gdb for that
+ <nalaginrut> for bochs, you don't have to use external debugger
+ <congzhang> thanks for explain
diff --git a/open_issues/default_pager.mdwn b/open_issues/default_pager.mdwn
new file mode 100644
index 00000000..38c9a2be
--- /dev/null
+++ b/open_issues/default_pager.mdwn
@@ -0,0 +1,44 @@
+[[!meta copyright="Copyright © 2011, 2012, 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]]."]]"""]]
+
+[[!tag open_issue_gnumach]]
+
+[[!toc]]
+
+
+# IRC, freenode, #hurd, 2011-08-31
+
+ <antrik> braunr: do you have any idea what could cause the paging errors
+ long before swap is exhausted?
+ <braunr> antrik: not really, but i know every project based on the mach vm
+ have rewritten their swap pager
+ <antrik> (and also I/O performance steadily dropping before that point is
+ reached?)
+
+[[performance/degradation]], [[ext2fs_page_cache_swapping_leak]].
+
+ <antrik> hm
+ <braunr> there could too many things
+ <antrik> perhaps we could "borrow" from one of them? :-)
+ <braunr> map entry fragmentation for example
+ <braunr> the freebsd one is the only possible candidate
+ <braunr> uvm is too different
+ <braunr> dragonflybsd maybe, but it's very close to freebsd
+ <braunr> i didn't look at darwin/xnu
+
+
+# [[trust_the_behavior_of_translators]]
+
+
+# IRC, freenode, #hurd, 2013-10-30
+
+ <braunr> it also seems that the kernel has trouble resuming processes that
+ have been swapped out
diff --git a/open_issues/dev_zero_size.mdwn b/open_issues/dev_zero_size.mdwn
new file mode 100644
index 00000000..20c5147e
--- /dev/null
+++ b/open_issues/dev_zero_size.mdwn
@@ -0,0 +1,21 @@
+[[!meta copyright="Copyright © 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]]
+
+IRC, freenode, #hurd, 2011-10-18:
+
+ <pinotree> i guess it is not normal for /dev/zero have a size of
+ (size_t)-1, no?
+ <pinotree> (it isn't (size_t)-1, but (long long)-1)
+
+2011-10-19:
+
+ <pinotree> see the size you get with `stat /dev/zero`
diff --git a/open_issues/device_drivers_and_io_systems.mdwn b/open_issues/device_drivers_and_io_systems.mdwn
new file mode 100644
index 00000000..085a737a
--- /dev/null
+++ b/open_issues/device_drivers_and_io_systems.mdwn
@@ -0,0 +1,100 @@
+[[!meta copyright="Copyright © 2009, 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]]
+
+This is a collection of resources concerning *device drivers* and *I/O systems*
+in general.
+
+Also see [[user-space device drivers]].
+[[community/gsoc/project ideas/driver glue code]].
+
+[[!toc levels=2]]
+
+
+# Documentation
+
+ * [An I/O System for Mach
+ 3.0](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.56.3210),
+ 1991, Alessandro Forin, David Golub, Brian Bershad
+
+ * [Linux Device Driver Emulation in
+ Mach](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.7252),
+ 1996, Shantanu Goel, Dan Duchamp
+
+ * [Eliminating receive livelock in an interrupt-driven
+ kernel](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.127.8257),
+ 1997, Jeffrey Mogul, Dec Western, Jeffrey C. Mogul, K. K. Ramakrishnan
+
+ * [IO-Lite: A Unified I/O Buffering and Caching
+ System](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.29.4224),
+ 1997, Vivek S. Pai, Peter Druschel, Willy Zwaenepoel
+
+ * [The Flux OSKit: A substrate for kernel and language
+ research](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.118.534),
+ 1997, Bryan Ford, Godmar Back, Greg Benson, Jay Lepreau, Albert Lin, Olin
+ Shivers
+
+ * [Reuse Linux Device Drivers in Embedded
+ Systems](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.26.6951),
+ 1998, Chi-wei Yang, Paul C. H. Lee, Ruei-Chuan Chang
+
+ * [THINK: A Software Framework for Component-based Operating System
+ Kernels](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.133.9239),
+ 2002, Jean-Philippe Fassino, Jean-Bernard Stefani, Julia Lawall, Gilles
+ Muller
+
+ * [An I/O Architecture for Microkernel-Based Operating
+ Systems](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.5.4337),
+ 2003, Hermann Haertig, Jork Loeser, Jork Löser, Frank Mehnert, Lars
+ Reuther, Martin Pohlack, Alexander Warg
+
+ * [High-Speed I/O: The Operating System as a Signalling
+ Mechanism](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.9.6991),
+ 2003, Matthew Burnside, Angelos D. Keromytis
+
+ * [Unmodified device driver reuse and improved system dependability via
+ virtual
+ machines](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.108.5317),
+ 2004, Joshua Levasseur, Volkmar Uhlig, Jan Stoess, Stefan Götz
+
+
+# External Projects
+
+ * [[/DDE]]
+
+ * [Building Linux Device Drivers on
+ FreeBSD](http://info.iet.unipi.it/~luigi/FreeBSD/linux_bsd_kld.html)
+
+ * [Project UDI](http://www.projectudi.org/), a multi-company effort to define
+ a Uniform Driver Interface
+
+ * [The Free Software Movement and
+ UDI](http://www.gnu.org/philosophy/udi.html)
+
+ * [OSKit](http://www.cs.utah.edu/flux/oskit/)
+
+ * [Unofficial OSKit source](http://www.nongnu.org/oskit/) on Savannah
+
+ * [[microkernel/Mach]]-like
+
+ It might be possible to integrate these systems' device drivers, as they're
+ expected to mostly be using the same interfaces as the current in-kernel
+ Mach drivers are.
+
+ * OSF Mach
+
+ * Darwin
+
+ * IRC, freenode, #hurd, 2013-08-26
+
+ < stargater> in haiku is a layer wraper for bsd driver
+ < stargater>
+ https://www.haiku-os.org/news/2007-05-08/haiku_getting_a_freebsd_network_driver_compatibility_layer
diff --git a/open_issues/dir-lookup_authority.mdwn b/open_issues/dir-lookup_authority.mdwn
new file mode 100644
index 00000000..64866eb5
--- /dev/null
+++ b/open_issues/dir-lookup_authority.mdwn
@@ -0,0 +1,68 @@
+[[!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_hurd]]
+
+IRC, unknown channel, unknown date.
+
+ <cfhammar> I have discovered a bug in the dir-lookup protocol though
+ <cfhammar> Currently, I'm investigating the bug a bit further
+ <cfhammar> when doing dir-lookups with several path components, the look-up is done with the authority of the user who opened the directory, as opposed to the user doing the lookup
+ <cfhammar> e.g, consider foo/bar/baz, where bar can only be used by its owner and foo and baz are world readable
+ <cfhammar> if foo is opened, then transferred to another user, he can open baz, which he shouldn't be able to
+ <cfhammar> this is possible where foo/bar/baz is within a single translator, and the lookup is done in a single dir-lookup
+ <antrik> cfhammar: I'm not sure this is a bug
+ <cfhammar> I have a test case that triggers the bug, and another that doesn't which currently confuses me
+ <antrik> cfhammar: it's probably not very usual to pass around open directory ports; but if somebody does it, it's probably actually desired that it keeps the authority
+ <antrik> it's kinda consistent with passing normal FDs
+ <cfhammar> antrik: it should only allow accesses to entries not sub-entries
+ <cfhammar> antrik: it isn't allowed in Linux atleast, and I'm guessing it's mandated by posix
+ <cfhammar> also note that a more common scenario is a process that opens a directory and then drops authority
+ <cfhammar> probably more common, that is
+ <antrik> cfhammar: I'm not really familiar with directory access functions... I wasn't even aware that it's possible to pass around directory FDs
+ <antrik> but if it is, it would indeed be good to know what POSIX says about this
+ <antrik> cfhammar: I don't see how this is related?...
+ <cfhammar> antrik: after the process has dropped authority it can still make lookups in directories that it should no longer be able to
+ <antrik> cfhammar: interesting point...
+ <antrik> cfhammar: do you think this is fixable?
+ <cfhammar> antrik: Not without (defacto) changing the interface
+ <cfhammar> e.g only looking up a singe path component at a time
+ <cfhammar> or doing the auth check lazily on io_reauthenticate
+ <antrik> cfhammar: yeah, obviously it's not possible without an API change. I just wonder whether it's possible without throwing the current auth/lookup mechanism overboard alltogether...
+ <cfhammar> antrik: both my solutions are only minor changes to the API, but fairly major in the sense that we need to change all callers :-(
+ <cfhammar> diskfs_S_dir_lookup is a very large function, for example
+ <antrik> cfhammar: OK
+ <antrik> cfhammar: I wonder whether there is a possible transition path without breaking all existing installations...
+ <cfhammar> we could provide a new RPC while supporting the old one
+ <cfhammar> note that changing fs.defs only affects glibc and the Hurd, normal apps should be fine
+ <antrik> cfhammar: have you posted your findings to the ML yet?
+ <cfhammar> No, I'm still investigating why my second test-case doesn't trigger the bug
+ <cfhammar> Intrestingly it's the one using all POSIX functions...
+ <cfhammar> Perhaps its a bug that maskes the lookup bug ;-)
+ <antrik> I guess there is some quirk which you do not fully understand yet :-)
+ <cfhammar> Oh, there's always a new quirk to find in the Hurd :-)
+ <cfhammar> antrik: seems that dir_lookup isn't buggy after all
+ <cfhammar> antrik: as all FDs are reauthenticated on setauth
+ <antrik> ah
+ <cfhammar> antrik: and (presumably) ports are unauthenticated and reauthenticated when transfered
+ <antrik> yeah, that's the idea behind the auth protocol...
+ <antrik> users obtain specific capabilities by authenticating generic ports against their own ID
+ <cfhammar> I didn't really have a coherent view on how open flags are handled on reauth
+ <cfhammar> it seems open flags always win, so that a O_READ port that is unauthed is still readable
+ <antrik> not sure what you mean
+ <cfhammar> if I open a file to read it, then reauth it with a user that isn't permitted to read it, I can still read from it
+ <cfhammar> (as it should be)
+ <cfhammar> by contrast permission to do lookups in a directory is determined by who authed it
+ <cfhammar> so I won't be able to do lookups after a reauth, if it's not permitted by the file bits
+ <youpi> Mmm, openat should however be able to
+ <youpi> since you've first opened the directory with the auth
+ <cfhammar> it isn't since open FDs are reauthed on setauth
+ <cfhammar> not sure whether it should though, Linux behaves the same way atleast
+ <cfhammar> though it could be done with POSIX.2008's O_SEARCH open flag
diff --git a/open_issues/duplicate_inclusion_guards.mdwn b/open_issues/duplicate_inclusion_guards.mdwn
new file mode 100644
index 00000000..1bb8fc36
--- /dev/null
+++ b/open_issues/duplicate_inclusion_guards.mdwn
@@ -0,0 +1,16 @@
+[[!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]]."]]"""]]
+
+[[!tag open_issue_mig]]
+
+E.g., both `/usr/include/hurd/process.h` and
+`/usr/include/hurd/process_request.h` use `_process_user_` as an inclusion
+guard. This leads to problems when both are needed, as is the case in
+[[GDB]]'s `gdb/gnu-nat.c`.
diff --git a/open_issues/e2fsck_i_file_acl_hi.mdwn b/open_issues/e2fsck_i_file_acl_hi.mdwn
new file mode 100644
index 00000000..d891ac6e
--- /dev/null
+++ b/open_issues/e2fsck_i_file_acl_hi.mdwn
@@ -0,0 +1,40 @@
+[[!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]]."]]"""]]
+
+IRC, unknown channel, unknown date.
+
+ <Duck> something's broken in ext2, fsck, or the like
+ <Duck> /dev/hd0s1: i_file_acl_hi for inode 81872 (/proc) is 32, shoud be 0.
+ <Duck> youpi: the other problem is probably related to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=526524
+ <Duck> i'll just check when it is fixed
+ <antrik> youpi: I've seen a lot of these fsck errors since the upgrade to 1.41.x
+ <antrik> youpi: seems to happen whenever a passive translator is still active while the machine reboots
+ <Duck> antrik: ho, so in my example this could be related to procfs then
+ <antrik> Duck: don't know... I got it with various terminal-related nodes
+ <antrik> other translators get terminated before ext2 it seems, so the problem doesn't happen there
+ <antrik> unless the machine crashes of course
+ <antrik> ah, right, it told you that it's the /proc node :-)
+ <antrik> was it the only node it complained about?
+ <antrik> Duck: ^
+ <Duck> antrik: yes, the only one
+ <youpi> so it's most probably i
+ <youpi> t
+ <Duck> but currently i don't have much translators around besides the base install
+ <antrik> that's strange... my theory about translators active at reboot seems wrong then
+ <youpi> well, maybe procps is not behaving properly
+ <youpi> procfs*
+ <antrik> youpi: I doubt it. I regularily get the same issue with various term nodes; and when the machine crashes rather than rebooting cleanly, many other nodes as well
+ <youpi> k
+ <antrik> but it's always passive translator nodes
+
+This is due to an erroneous read/write from e2fsck, see
+<http://sourceforge.net/tracker/?func=detail&aid=3379227&group_id=2406&atid=102406>.
+
+See [[!debbug 760275]]
diff --git a/open_issues/elinks.mdwn b/open_issues/elinks.mdwn
new file mode 100644
index 00000000..ee372971
--- /dev/null
+++ b/open_issues/elinks.mdwn
@@ -0,0 +1,28 @@
+[[!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_porting]]
+
+IRC, unknown channel, 2008-05-26 and later
+
+ <paakku> In elinks/src/network/state.h, there is an assumption that values of errno are between 0 and 100000. Now looking at glibc-2.5/sysdeps/mach/hurd/bits/errno.h, I see that you're using values outside this range. Have there been problems because of this?
+ <youpi> eeerf
+ <youpi> I had never seen a program assuming that
+ <youpi> that sucks
+ <paakku> It can be fixed, but that'd require some work, so I'd like to first have a clear idea of the effects.
+ <youpi> fixed where ?
+ <paakku> in elinks
+ <youpi> k
+ <paakku> by allocating just one number from our enum connection_state for system errors, and then stashing the errno value in a separate variable.
+ <paakku> Anyway, if you see this cause any user-visible bugs in ELinks, please report.
+
+ <kahmalo> I mentioned here on 2008-05-26 that ELinks assumes errno values are between 0 and 100000 whereas the Hurd uses other values. I fixed this in ELinks last weekend; the most recent 0.12 and 0.13 snapshots should include the fix. If you find any remaining errno assumptions, please post to: http://bugzilla.elinks.cz/show_bug.cgi?id=1013
+ <kahmalo> or to one of our mailing lists.
+ <kahmalo> I guess the pflocal select() bug http://savannah.gnu.org/bugs/?22861 is the primary hindrance to running ELinks on the Hurd. Has any decision been made on how that will be fixed?
diff --git a/open_issues/emacs.mdwn b/open_issues/emacs.mdwn
new file mode 100644
index 00000000..749649be
--- /dev/null
+++ b/open_issues/emacs.mdwn
@@ -0,0 +1,1542 @@
+[[!meta copyright="Copyright © 2009, 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]]."]]"""]]
+
+[[!meta title="GNU Emacs"]]
+
+[[!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]]
+
+
+---
+
+# 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 --
+ M-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 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=
+ M=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
+ Mhwinge 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;
+ M;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
+ M01;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:
+ M:*.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
+ M5:*.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
+ M01;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
+ Mm=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
+ Mnx=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:*.
+ M.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
+ Ml:\^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
+ MH: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
+ ME[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
+ ME[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
+ M140\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
+ ME[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
+ Mkb=\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[
+ M[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
+ Mcommand:/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=/
+ M/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/
+ M/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
+ Mf8 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
+ M192.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=/
+ M/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
+ M \^K cd src; make all \^K CC='gcc' CFLAGS='-g' CPPFLAGS='-DXASSERTS=1' \^K LDFLA
+ MAGS='-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
+ MEMACS=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
+ Md`/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?
+
+This is stock GNU Mach from Git, no patches, configured for Xen domU usage.
+
+
+# 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?
+
+
+## IRC, freenode, #hurd, 2013-10-07
+
+ <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/error_message_disk_full.mdwn b/open_issues/error_message_disk_full.mdwn
new file mode 100644
index 00000000..f72cd66a
--- /dev/null
+++ b/open_issues/error_message_disk_full.mdwn
@@ -0,0 +1,14 @@
+[[!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]]."]]"""]]
+
+IRC, unknown channel, unknown date:
+
+ <antrik> /usr/bin/install: writing `/usr/src/gnumach-20060408.dfsg.1/debian/gnumach-dbg/boot/gnumach': (os/kern) memory error
+ <antrik> interesting way to tell that the disk is full ;-)
diff --git a/open_issues/etc_fstab.mdwn b/open_issues/etc_fstab.mdwn
new file mode 100644
index 00000000..eb2a34f9
--- /dev/null
+++ b/open_issues/etc_fstab.mdwn
@@ -0,0 +1,18 @@
+[[!meta copyright="Copyright © 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="/etc/fstab"]]
+
+Even though we don't need a `/etc/fstab` for mounting filesystems
+(passive [[hurd/translator]]s to the rescue; they have problems on their
+own, see the [[hurd/critique]]), we still need this file for `fsck -a`
+and `swapon -a` to function.
+
+[[!tag open_issue_hurd]]
diff --git a/open_issues/exec.mdwn b/open_issues/exec.mdwn
new file mode 100644
index 00000000..05deaa7a
--- /dev/null
+++ b/open_issues/exec.mdwn
@@ -0,0 +1,84 @@
+[[!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
new file mode 100644
index 00000000..1fc5a928
--- /dev/null
+++ b/open_issues/exec_memory_leaks.mdwn
@@ -0,0 +1,121 @@
+[[!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/ext2fs_deadlock.mdwn b/open_issues/ext2fs_deadlock.mdwn
new file mode 100644
index 00000000..23f54a4a
--- /dev/null
+++ b/open_issues/ext2fs_deadlock.mdwn
@@ -0,0 +1,54 @@
+[[!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_hurd]]
+
+On 2010-10-26, [[I|tschwinge]]'ve been doing the following: `cp -a
+../tmpdir/dump*.o ./` (65 files), changed my mind, hit `C-c`, continued with
+`cp -a ../tmpdir/dump*.o ./` (to preserve timestamps), wondered why this takes
+so long, hit `C-c` again, then found the FS deadlocked (using no CPU; but
+`syncfs -s -c` wouldn't finish, for example). Judging from the files'
+timestamps (after rebooting and `fsck`), I would assume that it already hung at
+the second `cp`'s time, and the deadlock thus is not due to the second `C-c`,
+but due to the first one.
+
+ # gdb /hurd/ext2fs
+ [...]
+ (gdb) set noninvasive on
+ (gdb) attach 177
+ [...]
+ [New Thread 177.535]
+ Reading symbols [...]
+ (gdb) info threads
+ [all the same from 177.535 down to...]
+ 11 Thread 177.11 0x010e3efc in mach_msg_trap ()
+ at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
+ 10 Thread 177.10 0x010e3efc in mach_msg_trap ()
+ at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
+ [doesn't continue with thread 9, but hangs, taking all CPU time]
+
+New GDB instance, again noninvasive, I'm able to continue.
+
+Here are backtraces for threads [[1 to 8|bt_1-8]] and [[10 to 535|bt_10-535]],
+I didn't succeed to get any information about thread 9 (which thus would
+probably be the most interesting one...) -- GDB would always hang when
+accessing it, no matter whether noninvasive mode or not. (Didn't have time to
+pull the information out of the process' memory manually (how to do that,
+anyways?), and also didn't have time to continue with debugging GDB itself, but
+this sounds like a [[!taglink open_issue_gdb]]...)
+
+
+# IRC, freenode, #hurd, 2010-10-27
+
+ <youpi> thread 8 hung on ports_begin_rpc
+ <youpi> that's probably where one could investigated first
+ <youpi> yes, a lot of threads are hung on that
+ <tschwinge> You mean 0x10b9488, right?
+ <youpi> yes
diff --git a/open_issues/ext2fs_dtime.mdwn b/open_issues/ext2fs_dtime.mdwn
new file mode 100644
index 00000000..592f1525
--- /dev/null
+++ b/open_issues/ext2fs_dtime.mdwn
@@ -0,0 +1,21 @@
+[[!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_hurd]]
+
+ /dev/hd0s1: Deleted inode 95849 has zero dtime. FIXED.
+
+This is actually sorta benign. What typically happens is that one upgrades e.g.
+a library, and there are still some processes using it (e.g. because it's libc).
+The library file is thus kept on the filesystem, so as to be able to load parts
+of it on demand. The file is thus marked as deleted, but the deletion hasn't
+been effective yet, thus dtime being zero. e2fsck notices this and finishes
+deleting the file. To really fix this, we would probably have to really unmount
+the filesystem.
diff --git a/open_issues/ext2fs_libports_reference_counting_assertion.mdwn b/open_issues/ext2fs_libports_reference_counting_assertion.mdwn
new file mode 100644
index 00000000..2b9f28e8
--- /dev/null
+++ b/open_issues/ext2fs_libports_reference_counting_assertion.mdwn
@@ -0,0 +1,111 @@
+[[!meta copyright="Copyright © 2012, 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]]."]]"""]]
+
+[[!tag open_issue_hurd]]
+
+ libports/port-ref.c:31: ports_port_ref: Assertion `pi->refcnt || pi->weakrefcnt' failed
+
+This is seen every now and then.
+
+
+# [[gnumach_page_cache_policy]]
+
+With that patch in place, the assertion failure is seen more often.
+
+
+## IRC, freenode, #hurd, 2012-07-14
+
+ <youpi> braunr: I'm getting ext2fs.static:
+ /usr/src/hurd-debian/./libports/port-ref.c:31: ports_port_ref: Assertion
+ `pi->refcnt || pi->weakrefcnt' failed.
+ <youpi> oddly enough, that happens on one of the buildds only
+ <braunr> :/
+ <braunr> i fear the patch can wake many of these issues
+
+
+## IRC, freenode, #hurd, 2012-07-15
+
+ <youpi> braunr: same assertion failed on a second buildd
+ <braunr> can you paste it again please ?
+ <youpi> ext2fs.static: /usr/src/hurd-debian/./libports/port-ref.c:31:
+ ports_port_ref: Assertion `pi->refcnt || pi->weakrefcnt' failed.
+ <braunr> or better, answer the ml thread for future reference
+ <braunr> thanks
+ <youpi> braunr: I can't keep your patch on the buildds, it makes them too
+ unreliable
+ <braunr> youpi: ok
+ <braunr> i never got this error though, that's weird
+ <braunr> youpi: was the failure during the same build ?
+ <youpi> no, it was during package installation, and not the same
+ <youpi> braunr: note that I've already seen such errors, it's not new, but
+ it was way rarer
+ <youpi> like every month only
+ <braunr> ah ok
+ <braunr> yes it's less surprising then
+ <braunr> a tricky reference counting / locking mistake somewhere in the
+ hurd :) ...
+ <braunr> ah ! just got it !
+ <bddebian> braunr: Got the error or found the problem? :)
+ <braunr> the former unfortunately :/
+
+
+## IRC, freenode, #hurd, 2012-07-19
+
+ <braunr> hm, i think those ext2fs port refs errors may also be due to stack
+ overflows
+ <pinotree> --verbose
+ <braunr> hm ?
+ <braunr> http://lists.gnu.org/archive/html/bug-hurd/2012-07/msg00051.html
+ <pinotree> i mean, why do you think they could be due to that?
+ <braunr> the error is that both strong and weak refs in a port are 0 when
+ adding a reference
+ <braunr> weak refs are almost never used so let's forget about them
+ <braunr> when a ref count drops to 0, the port is automatically deallocated
+ <braunr> so what other than memory corruption setting this counter to 0
+ could possibly do that ? :)
+ <pinotree> one could also guess an unbalanced ref/unref logic, somehow
+ <braunr> what do you mean ?
+ <pinotree> that for a bug, an early return, etc a port gets unref'ed often
+ than it is ref'ed
+ <braunr> highly unlikely, as they're protected by a lock
+ <braunr> pinotree: ah you mean, the object gets deallocated early because
+ of an deref overflow ?
+ <braunr> pinotree: could be, yes
+ <braunr> pinotree: i wonder if it could happen because of the periodic sync
+ duplicating the node table without holding references
+ <braunr> rah, libports uses a big lock in many places :(
+ <pinotree> braunr: yes, i meant that
+ <braunr> we could try using libduma some day
+ <braunr> i wonder if it could work out of the box
+ <pinotree> but that wouldn't help to find out whether a port gets deref'ed
+ too often, for instance
+ <pinotree> although it could be adapted to do so, i guess
+ <braunr> reproducing + a call trace or core would be best, but i'm not even
+ sure we can get that easily lol
+
+[[automatic_backtraces_when_assertions_hit]].
+
+
+# IRC, freenode, #hurd, 2013-10-09
+
+ <braunr> mhmm, i may have an explanation for the weird assertions we
+ sometimes see in ext2fs
+ <braunr> glibc uses alloca to reserve memory for one reply port per thread
+ in abort_all_rpcs
+ <braunr> if this erases the thread-specific area, we can expect all kinds
+ of wreckage
+ <braunr> i'm not sure how to fix this though
+
+
+# IRC, freenode, #hurd, 2014-01-29
+
+ <gg0> ext2fs: ../../libports/port-ref.c:30: ports_port_ref: Assertion
+ `pi->refcnt || pi->weakrefcnt' failed.
diff --git a/open_issues/ext2fs_page_cache_swapping_leak.mdwn b/open_issues/ext2fs_page_cache_swapping_leak.mdwn
new file mode 100644
index 00000000..81915492
--- /dev/null
+++ b/open_issues/ext2fs_page_cache_swapping_leak.mdwn
@@ -0,0 +1,361 @@
+[[!meta copyright="Copyright © 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_gnumach open_issue_hurd]]
+
+There is a [[!FF_project 272]][[!tag bounty]] on this task.
+
+[[!toc]]
+
+
+# IRC, OFTC, #debian-hurd, 2011-03-24
+
+ <youpi> I still believe we have an ext2fs page cache swapping leak, however
+ <youpi> as the 1.8GiB swap was full, yet the ld process was only 1.5GiB big
+ <pinotree> a leak at swapping time, you mean?
+ <youpi> I mean the ext2fs page cache being swapped out instead of simply
+ dropped
+ <pinotree> ah
+ <pinotree> so the swap tends to accumulate unuseful stuff, i see
+ <youpi> yes
+ <youpi> the disk content, basicallyt :)
+
+
+# IRC, freenode, #hurd, 2011-04-18
+
+ <antrik> damn, a cp -a simply gobbles down swap space...
+ <braunr> really ?
+ <braunr> that's weird
+ <braunr> why would a copy use so much anonymous memory ?
+ <braunr> unless the external pager is so busy that the kernel falls back to
+ its default pager
+ <youpi> that's what I suggested some time ago
+ <braunr> maybe this case should be traced in the kernel
+ <braunr> a simple message in the kernel buffer to warn that this condition
+ happened may help
+ <youpi> I'm seeing swap space being kept used on buildds for no real reason
+ except possibly backing ext2fs pages
+ <youpi> that could help, yes
+ <antrik> youpi: I think it was actually slpz who suggested that...
+ <youpi> I think we're generally missing feedback from memory behavior
+ <antrik> youpi: do you think andrei's kernel instrumentation work might be
+ helpful with analyzing such things?
+ <youpi> antrik: I think I suggested it too, but never mind
+ <youpi> antrik: no, because it's not a trace of events that you want
+ <youpi> some specific events would be useful
+ <youpi> but then we don't really need a whole framework for that
+ <antrik> apt-get upgrade eats swap too
+ <youpi> the upgrade itself, or the computation of the ugprade?
+ <youpi> apt is a memory eater nowadays
+ <antrik> installing the packages
+ <antrik> seems to have stabilized though after a while...
+ <antrik> so perhaps it's not a leak in this case
+ <youpi> ideally we should have a way to know what was put in the swap
+ <braunr> how would you represent what's in the swap ?
+ <antrik> the apt-get process has 46M of virtual memory above the 128 M
+ baseline
+ <braunr> mostly libraries i guess
+ <braunr> are trheads stacks 8 MiB like on Linux ?
+ <youpi> braunr: at least knowing how much of each process is in the swap
+ <youpi> braunr: 2MiB
+ <braunr> ok
+ <youpi> vminfo could also report which parts of the address space are in
+ the swap
+ <antrik> youpi: would be nice to have some simple utility reporting how
+ much of a process' address space is anonymous
+ <antrik> (in fact, I wonder why it's not reported by standard tools such as
+ ps or top... this shouldn't be too difficult I would think?)
+ <antrik> it would be much more useful information than the total virt size,
+ which includes rather meaningless disk and device mappings...
+ <youpi> agreed
+ <braunr> well
+ <braunr> there are tools like pmap for this
+ <braunr> unfortunately, it's difficult in mach to know what backs a
+ non-anonymous mapping
+ <braunr> pagers should be able to name their mappings
+ <youpi> that'd be helpful for debugging yes
+ <braunr> there is almost no overhead in doing that, and it would be very
+ useful
+ <youpi> and could lead to /proc/pid/maps
+ <braunr> yes
+ <braunr> isn't there a maps already ?
+ <youpi> nope
+ <braunr> ok
+ <youpi> (probably not very useful without the names)
+ <braunr> ithought i remembered maps without names, and guessed it might
+ have been on the hurd for that reason
+ <braunr> but i'm not sure
+ <youpi> there's the vminfo command, yes
+ <braunr> 14:06 < youpi> braunr: at least knowing how much of each process
+ is in the swap
+ <braunr> wouldn't it be clearer to do it the other way around ?
+ <braunr> like a swapinfo tool indicating what it contains ?
+ <youpi> sure, but it's a lot more difficult
+ <braunr> really ?
+ <braunr> why ?
+ <youpi> because you have to traverse all the mappings
+ <youpi> etc
+ <youpi> (in all processes, I mean)
+ <youpi> and you have to name what is waht
+ <braunr> there are other ways
+ <braunr> the swap is a central structure
+ <youpi> while simply introducing the swap % in vminfo
+ <youpi> for a given process you know what is what
+ <braunr> right
+ <youpi> and doing that introduction is probably very simple
+ <braunr> that's a good point
+ <braunr> top-down is effectively easier than bottom-up resolution in Mach
+ VM
+ <antrik> hm... the memory use caused by cp doesn't seem to be reflected in
+ the virtual size of any particular process
+ <antrik> ghost memory
+ <braunr> what's cp vmsize at the time of the problem ?
+ <antrik> it's at 134 M right now... so considering the 128 M baseline,
+ nothing worth speaking of
+ <braunr> right
+ <braunr> maybe a copy map during I/O
+ <braunr> but I don't know Mach copy maps in detail, as they have been
+ eliminated from UVM
+ <antrik> BTW, the memory eatup happens even before swap comes into
+ play... swapping seems to be a result of the problem, not the cause
+ <braunr> what do you mean ?
+ <braunr> I thought swapping was the issue
+ <braunr> you mean RAM is full before swapping ?
+ <antrik> well, I don't know what the actual problem is... I just don't
+ understand why the memory use increases without any particular process
+ seeing an increase in size
+ <antrik> the "free" size in vmstat decreses
+ <antrik> once it's eatun up, swap space use increases
+ <braunr> well it doesn't change much of it
+ <braunr> the anonymous memory pager will use RAM before resorting to the
+ external default-pager
+ <antrik> I would suspect normal block caching... but then, shouldn't this
+ show up in the memory info of the ext2 process?
+ <braunr> although, again, I'm not sure of the behaviour of the anonymous
+ memory pager
+ <braunr> antrik: I don't know how block caching behaves
+ <antrik> BTW, is it a know problem that doing ^C on a "cp -a" seems to hang
+ the whole system?...
+ <antrik> (the whole hurd instance that is... the other instance is not
+ affected)
+ <youpi> not that I know of
+ <braunr> seems like a deadlock in the anonymous memory handling
+ <youpi> (and I've never seen that)
+ <antrik> happens both in my main system (using ancient hurd/libc) and in my
+ subhurd (recently upgraded to current stuff)
+ <antrik> this make testing this stuff quite a lot harder... [sigh]
+ <antrik> any suggestions how to debug this hang?
+ <braunr> antrik: no :/
+
+2011-04-28: [[!taglink open_issue_documentation]]
+
+ <antrik> hm... is it normal that "swap free" doesn't increase as a process'
+ memory is paged back in?
+ <youpi> yes
+ <youpi> there's no real use cleaning swap
+ <youpi> on the contrary, it makes paging the process out again longer
+ <antrik> hm... so essentially, after swapping back and forth a bit, a part
+ of the swap equal to the size of physical RAM will be occupied with stuff
+ that is actually in RAM?
+ <youpi> yes
+ <youpi> so that that RAM can be freed immediately if needed
+ <antrik> hm... that means my effective swap size is only like 300 MB... no
+ wonder I see crashes under load
+ <antrik> err... make that 230 actually
+ <antrik> indeed, quitting the application freed both the physical RAM and
+ swap space
+ <braunr> 02:28 < antrik> hm... is it normal that "swap free" doesn't
+ increase as a process' memory is paged back in?
+ <braunr> swap is the backing store of anonymous memory, like ext2fs is the
+ backing store of memory objects created from its pager
+ <braunr> so you can view swap as the file system for everything that isn't
+ an external memory object
+
+
+# IRC, freenode, #hurd, 2011-11-15
+
+ <braunr> hm, now my system got unstable
+ <braunr> swap is increasing, without any apparent reason
+ <antrik> you mean without any load?
+ <braunr> with load, yes
+ <braunr> :)
+ <antrik> well, with load is "normal"...
+ <antrik> at least for some loads
+ <braunr> i can't create memory pressure to stress reclaiming without any
+ load
+ <antrik> what load are you using?
+ <braunr> ftp mirrorring
+ <antrik> hm... never tried that; but I guess it's similar to apt-get
+ <antrik> so yes, that's "normal". I talked about it several times, and also
+ wrote to the ML
+ <braunr> antrik: ok
+ <antrik> if you find out how to fix this, you are my hero ;-)
+ <braunr> arg :)
+ <antrik> I suspect it's the infamous double swapping problem; but that's
+ just a guess
+ <braunr> looks like this
+ <antrik> BTW, if you give me the exact command, I could check if I see it
+ too
+ <braunr> i use lftp (mirror -Re) from a linux git repository
+ <braunr> through sftp
+ <braunr> (lots of small files, big content)
+ <antrik> can't you just give me the exact command? I don't feel like
+ figuring it out myself
+ <braunr> antrik: cd linux-stable; lftp sftp://hurd_addr/
+ <braunr> inside lftp: mkdir linux-stable; cd linux-stable; mirror -Re
+ <braunr> hm, half of physical memory just got freed
+ <braunr> our page cache is really weird :/
+ <braunr> (i didn't delete any file when that happened)
+ <antrik> hurd_addr?
+ <braunr> ssh server ip address
+ <braunr> or name
+ <braunr> of your hurd :)
+ <antrik> I'm confused. you are mirroring *from* the Hurd box?
+ <braunr> no, to it
+ <antrik> ah, so you login via sftp and then push to it?
+ <braunr> yes
+ <braunr> fragmentation looks very fine
+ <braunr> even for the huge pv_entry cache and its 60k+ entries
+ <braunr> (and i'm running a kernel with the cpu layer enabled)
+ <braunr> git reset/status/diff/log/grep all work correctly
+ <braunr> anyway, mcsim's branch looks quite stable to me
+ <antrik> braunr: I can't reproduce the swap leak with ftp. free memory
+ idles around 6.5 k (seems to be the threshold where paging starts), and
+ swap use is constant
+ <antrik> might be because everything swappable is already present in swap
+ from previous load I guess...
+ <antrik> err... scratch that. was connected to the wrong host, silly me
+ <antrik> indeed swap gets eaten away, as expected
+ <antrik> but only if free memory actually falls below the
+ threshold. otherwise it just oscillates around a constant value, and
+ never touches swap
+ <antrik> so this seems to confirm the double swapping theory
+ <youpi> antrik: is that "double swap" theory written somewhere?
+ <youpi> (no, a quick google didn't tell me)
+
+
+## IRC, freenode, #hurd, 2011-11-16
+
+ <antrik> youpi:
+ http://lists.gnu.org/archive/html/l4-hurd/2002-06/msg00001.html talks
+ about "double paging". probably it's also the term others used for it;
+ however, the term is generally used in a completely different meaning, so
+ I guess it's not really suitable for googling either ;-)
+ <antrik> IIRC slpz (or perhaps someone else?) proposed a solution to this,
+ but I don't remember any details
+ <youpi> ok so it's the same thing I was thinking about with swap getting
+ filled
+ <youpi> my question was: is there something to release the double swap,
+ once the ext2fs pager managed to recover?
+ <antrik> apparently not
+ <antrik> the only way to free the memory seems to be terminating the FS
+ server
+ <youpi> uh :/
+
+
+# IRC, freenode, #hurd, 2011-11-30
+
+ <antrik> slpz: basically, whenever free memory goes below the paging
+ threshold (which seems to be around 6 MiB) while there is other I/O
+ happening, swap usage begins to increase continuously; and only gets
+ freed again when the filesystem translator in question exits
+ <antrik> so it sounds *very* much like pages go to swap because the
+ filesystem isn't quick enough to properly page them out
+ <antrik> slpz: I think it was you who talked about double paging a while
+ back?
+ <slpz> antrik: probably, sounds like me :-)
+ <antrik> slpz: I have some indication that the degenerating performance and
+ ultimate hang issues I'm seeing are partially or entirely caused by
+ double paging...
+ <antrik> slpz: I don't remember, did you propose some possible fix?
+ <slpz> antrik: hmm... perhaps it wasn't me, because I don't remember trying
+ to fix that problem...
+ <slpz> antrik: at which point do you think pages get duplicated?
+ <antrik> slpz: it was a question. I don't remember whether you proposed
+ something or not :-)
+ <antrik> slpz: basically, whenever free memory goes below the paging
+ threshold (which seems to be around 6 MiB) while there is other I/O
+ happening, swap usage begins to increase continuously; and only gets
+ freed again when the filesystem translator in question exits
+ <antrik> so it sounds *very* much like pages go to swap because the
+ filesystem isn't quick enough to properly page them out
+ <slpz> antrik: I see
+ <slpz> antrik: I didn't addressed this problem directly, but when I've
+ modified the pageout mechanism to provide a special treatment for
+ external pages, I also removed the possibility of sending them to the
+ default pager
+ <slpz> antrik: this was in my experimental environment, of course
+ <antrik> slpz: oh, nice... so it may fix the issues I'm seeing? :-)
+ <antrik> anything testable yet?
+ <slpz> antrik: yes, only anonymous memory could be swapped with that
+ <slpz> antrik: it works, but is ugly as hell
+ <antrik> tschwinge: these is also your observation about compilations
+ getting slower on further runs, and my followups... I *suspect* it's the
+ same issue
+
+[[performance/degradation]].
+
+ <slpz> antrik: I'm thinking about establishing a repository for these
+ experimental versions, so they don't get lost with the time
+ <antrik> slpz: please do :-)
+ <slpz> antrik: perhaps in savannah's HARD project
+ <antrik> even if it's not ready for upstream, it would be nice if I could
+ test it -- right now it's bothering me more than any other Hurd issues I
+ think...
+ <slpz> also, there's another problem which causes performance degradation
+ with the simple use of the system
+ <tschwinge> slpz: Please just push to Savannah Hurd. Under your
+ slpz/... or similar.
+ <tschwinge> antrik: Might very well be, yes.
+ <slpz> and I almost sure it is the fragmentation of the task map
+ <slpz> tschwinge: ok
+ <slpz> after playing a bit with a translator, it can easily get more than
+ 3000 entries in its map
+ <antrik> slpz: yeah, other issues might play a role here as well. I
+ observed that terminating the problematic FS servers does free most of
+ the memory and remove most of the performance degradation, but in some
+ cases it's still very slow
+ <slpz> that makes vm_map_lookup a lot slower
+ <antrik> on a related note: any idea what can cause paging errors and a
+ system hang even when there is plenty of free swap?
+ <antrik> (I'm not entirely sure, but my impression is that it *might* be
+ related to the swap usage and performance degradation problems)
+ <slpz> I think this degree of fragmentation has something to do with the
+ reiterative mapping of memory objects which is done in pager-memcpy.c
+ <slpz> antrik: which kind of paging errors?
+ <antrik> hm... I don't think I ever noted down the exact message; but I
+ think it's the same you get when actually running out of swap
+ <slpz> antrik: that could be the default pager dying for some internal bug
+ <antrik> well, but it *seems* to go along with the performance degradation
+ and/or swap usage
+ <slpz> I also have the impression that we're using memory objects the wrong
+ way
+ <antrik> basically, once I get to a certain level of swap use and slowness
+ (after about a month of use), the system eventually dies
+ <slpz> antrik: I never had a system running for that time, so it could be a
+ completely different problem from what I've seen before :-/
+ <slpz> Anybody has experience with block-level caches on microkernel
+ environments?
+ <antrik> slpz: yeah, it typically happens after about a month of my normal
+ use... but I can significantly accellerate it by putting some problematic
+ load on it, such as large apt-get runs...
+ <slpz> I wonder if it would be better to put them in kernel or in user
+ space. And in the latter, if it would be better to have one per-device
+ shared for all accesing translators, or just each task should have its
+ own cache...
+ <antrik> slpz:
+ http://lists.gnu.org/archive/html/bug-hurd/2011-09/msg00041.html is where
+ I described the issue(s)
+ <antrik> (should send another update for the most recent findings I
+ guess...)
+ <antrik> slpz: well, if we move to userspace drivers, the kernel part of
+ the question is already answered ;-)
+ <antrik> but I'm not sure about per-device cache vs. caching in FS server
diff --git a/open_issues/extern_inline.mdwn b/open_issues/extern_inline.mdwn
new file mode 100644
index 00000000..a3a22b16
--- /dev/null
+++ b/open_issues/extern_inline.mdwn
@@ -0,0 +1,109 @@
+[[!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_hurd]]
+
+[[!toc]]
+
+
+# IRC, unknown channel, unknown date
+
+ <tschwinge> youpi: Did you ever review the Savannah hurd branch master-fix_extern_inline?
+ <youpi> why static inlines instead of extern lines ?
+ <youpi> +in
+ <youpi> static inlines can lead to space waste where it isn't inlined
+ <tschwinge> Are you sure about that -- I don't think so.
+ <tschwinge> At least with 99 inlining.
+ <youpi> what can the compiler do where it isn't inlined ?
+ <youpi> include a copy
+ <youpi> thus space waste
+ <youpi> 00000000004004b1 t f
+ <youpi> 00000000004004d5 t f
+ <youpi> I've juste checked
+ <youpi> two copies of my inline function
+ <youpi> one per .o
+ <tschwinge> Yes, but isn't it expected tobe that way? ARen't these functions those that are never included in a libarary, as opposed to those which I switched to __extern_inline in the next patch?
+ <tschwinge> It's been a long time that I had a look at this...
+ <tschwinge> The problem with the patch from the Debian package is that the functions didn't end up in the libraries anymore.
+ <youpi> ah you mean these are private functions and thus shouldn't be exposed (unexpected_reply for instance)
+ <youpi> but the duplication issue still holds
+ <youpi> the functions not ending up in the library is a concern indeed
+ <tschwinge> That's what my second patch fixes, I think.
+ <youpi> grah, callisto rebooted for no reason
+ <youpi> ah, indeed the second patch fixes things correctly
+ <youpi> uh, indeed it's --dbg-package=hurd in there
+ <youpi> how odd
+ <youpi> tschwinge: for the libftpconn case, yes unexpected_reply should probably be a static inline
+ <tschwinge> Is this true:
+ <tschwinge> static inline -- either inline or emit a local symbol vs. extern inline -- either inline or emit a reference to an external symbol.
+ <youpi> so as to not expose it
+ <youpi> for other cases we can keep an extern inline as they are just programs
+ <tschwinge> Then everything that's not expected to end up in a libarary must be static inline, as otherwise, when the compiler can't inline, there wouldn't be a reference to it available.
+ <youpi> and that avoids duplicate code
+ <youpi> yes
+ <youpi> but as long as you provide the extern inlines by compiling an xinl.c there's no problem
+ <tschwinge> Sure, that'd be the alternative.
+ <youpi> for libraries you need to take care of the symbols you want to export (which can thus be in xinl.c), and those you don't want to export (and thus keep static inlines)
+ <tschwinge> So you say it'd be better to do that (xinl.c) instead of static inline?
+ <youpi> for programs, you can just keep them all extern inlines
+ <youpi> yes, it shares code
+ <youpi> it's only in the case of symbols that shouldn't be exported by the library that we need to use static inlines
+ <tschwinge> ANd in .c files that are part of programs I'd also use extern inline or static inline?
+ <youpi> for programs just always use extern lines
+ <youpi> +in
+ <youpi> as you don't care about symbol exposure
+ <youpi> unless the inline is defined in a .c file of course, in that case it's useless to make it extern
+ <tschwinge> But then I also always need xinl.c files for those, which we apparently don't have in a few places.
+ <youpi> yes
+ <tschwinge> But probably didn't notice so far, as the functions could always be inlined.
+ <youpi> probably because we used to have luck
+ <youpi> yes
+ <tschwinge> Yes, I was thinking about the term/munge.c thing.
+ <tschwinge> OK, I think I get it now. Then I'll try to fix this accordingly.
+ <tschwinge> But not now. Thanks for the help!
+ <youpi> ok, thanks
+ <tschwinge> It was quite a bit confusing to me.
+ <tschwinge> Due to the mostly reversed definition of extern inline in glibc (I think).
+ <youpi> inline definitely is confusing
+ <youpi> especially since the semantic has changed over time and according to standards :)
+ <tschwinge> And then GCC changing that according to C99.
+ <tschwinge> Yes.
+
+
+# IRC, freenode, #hurd, 2012-03-14
+
+ <youpi>
+ http://anonscm.debian.org/gitweb/?p=pkg-hurd/hurd.git;a=blob;f=debian/patches/extern_inline_fix.patch;h=b9eacbff97dc56e99a69ddb601a5fc948f6e44a7;hb=HEAD
+ <youpi> maybe review it, and then we apply it
+ <pinotree>
+ http://patch-tracker.debian.org/patch/series/view/hurd/20120222-1/extern_inline_fix.patch
+ ;)
+ <civodul> youpi: the #ifdef __USE_EXTERN_INLINES in there and the extra
+ "extern" decls look wrong to me
+ <youpi> iirc USE_EXTERN_INLINES is needed
+ <youpi> otherwise it's not compliant
+ <youpi> or maybe it's for -O0
+ <youpi> anyway IIRC it's needed
+ <civodul> when !defined __USE_EXTERN_INLINES, you end up with extern decls
+ with no corresponding definition
+ <youpi> yes
+ <youpi> they are defined in the code
+ <civodul> where?
+ <youpi> there's a special .c file in each lib
+ <youpi> libdiskfs/extern-inline.c
+ <youpi> etc
+ <civodul> oooh, right
+ <youpi> extern inline means that anyway
+ <youpi> the compiler is allowed to not always inline
+ <civodul> yes
+ <civodul> that looks good to me, then
+ <civodul> youpi: can you apply it, with proper authorship & co.?
+ <civodul> (no rush, though)
+ <youpi> sure
diff --git a/open_issues/faccessat.mdwn b/open_issues/faccessat.mdwn
new file mode 100644
index 00000000..911acbb6
--- /dev/null
+++ b/open_issues/faccessat.mdwn
@@ -0,0 +1,21 @@
+[[!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/fakeroot_eagain.mdwn b/open_issues/fakeroot_eagain.mdwn
new file mode 100644
index 00000000..168ddf7d
--- /dev/null
+++ b/open_issues/fakeroot_eagain.mdwn
@@ -0,0 +1,216 @@
+[[!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 open_issue_porting]]
+
+
+# IRC, freenode, #hurd, 2012-12-05
+
+ <braunr> rbraun 18813 R 2hrs ln -sf ../af_ZA/LC_NUMERIC
+ debian/locales-all/usr/lib/locale/en_BW/LC_NUMERIC
+ <braunr> when building glibc
+ <braunr> is this a known issue ?
+ <tschwinge> braunr: No. Can you get a backtrace?
+ <braunr> tschwinge: with gdb you mean ?
+ <tschwinge> Yes. If you have any debugging symbols (glibc?).
+ <braunr> or the build log leading to that ?
+ <braunr> ok, i will next time i have it
+ <tschwinge> OK.
+ <braunr> (i regularly had it when working on the pthreads port)
+ <braunr> tschwinge:
+ http://www.sceen.net/~rbraun/hurd_glibc_build_deadlock_trace
+ <braunr> youpi: ^
+ <youpi> Mmm, there's not so much we can do about this one
+ <braunr> youpi: what do you mean ?
+ <youpi> the problem is that it's really a reentrency issue of the libc
+ locale
+ <youpi> it would happen just the same on linux
+ <braunr> sure
+ <braunr> but hat doesn't mean we can't report and/or fix it :)
+ <youpi> (the _nl_state_lock)
+ <braunr> do you have any workaround in mind ?
+ <youpi> no
+ <youpi> actually that's what I meant by "there's not so much we can do
+ about this"
+ <braunr> ok
+ <youpi> because it's a bad interaction between libfakeroot and glibc
+ <youpi> glibc believe fxtstat64 would never call locale functions
+ <youpi> but with libfakeroot it does
+ <braunr> i see
+ <youpi> only because we get an EAGAIN here
+ <braunr> but hm, doesn't it happen on linux ?
+ <youpi> EAGAIN doesn't happen on linux for fxstat64, no :)
+ <braunr> why does it happen on the hurd ?
+ <youpi> I mean for fakeroot stuff
+ <youpi> probably because fakeroot uses socket functions
+ <youpi> for which we probably don't properly handleEAGAIN
+ <youpi> I've already seen such kind of issue
+ <youpi> in buildd failures
+ <braunr> ok
+ <youpi> (so the actual bug here is EAGAIN
+ <youpi> )
+ <braunr> yes, so we can do something about it
+ <braunr> worth a look
+ <pinotree> (implement sysv semaphores)
+ <youpi> pinotree: if we could also solve all these buildd EAGAIN issues
+ that'd be nice :)
+ <braunr> that EAGAIN error might also be what makes exim behave badly and
+ loop forever
+ <youpi> possibly
+ <braunr> i've updated the trace with debugging symbols
+ <braunr> it fails on connect
+ <pinotree> like http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=563342 ?
+ <braunr> it's EAGAIN, not ECONNREFUSED
+ <pinotree> ah ok
+ <braunr> might be an error in tcp_v4_get_port
+
+
+## IRC, freenode, #hurd, 2012-12-06
+
+ <braunr> hmm, tcp_v4_get_port sometimes fails indeed
+ <gnu_srs> braunr: may I ask how you found out, adding print statements in
+ pfinet, or?
+ <braunr> yes
+ <gnu_srs> OK, so that's the only (easy) way to debug.
+ <braunr> that's the last resort
+ <braunr> gdb is easy too
+ <braunr> i could have added a breakpoint too
+ <braunr> but i didn't want to block pfinet while i was away
+ <braunr> is it possible to force the use of fakeroot-tcp on linux ?
+ <braunr> the problem seems to be that fakeroot doesn't close the sockets
+ that it connected to faked-tcp
+ <braunr> which, at some point, exhauts the port space
+ <pinotree> braunr: sure
+ <pinotree> change the fakeroot dpkg alternative
+ <braunr> ok
+ <pinotree> calling it explicitly `fakeroot-tcp command` or
+ `dpkg-buildpackage -rfakeroot-tcp ...` should work too
+ <braunr> fakeroot-tcp looks really evil :p
+ <braunr> hum, i don't see any faked-tcp process on linux :/
+ <pinotree> not even with `fakeroot-tcp bash -c "sleep 10"`?
+ <braunr> pinotree: now yes
+ <braunr> but, does it mean faked-tcp is started for *each* process loading
+ fakeroot-tcp ?
+ <braunr> (the lib i mean)
+ <pinotree> i think so
+ <braunr> well the hurd doesn't seem to do that at all
+ <braunr> or maybe it does and i don't see it
+ <braunr> the stale faked-tcp processes could be those that failed something
+ only
+ <pinotree> yes, there's also that issue: sometimes there are stake
+ faked-tcp processes
+ <braunr> hum no, i see one faked-tcp that consumes cpu when building glibc
+ <pinotree> *stale
+ <braunr> it's the same process for all commands
+ <pinotree> <braunr> but, does it mean faked-tcp is started for *each*
+ process loading fakeroot-tcp ?
+ <pinotree> → everytime you start fakeroot, there's a new faked-xxx for it
+ <braunr> it doesn't look that way
+ <braunr> again, on the hurd, i see one faked-tcp, consuming cpu while
+ building so i assume it services libfakeroot-tcp requests
+ <pinotree> yes
+ <braunr> which means i probably won't reproduce the problem on linux
+ <pinotree> it serves that fakeroot under which the binary(-arch) target is
+ run
+ <braunr> or perhaps it's the normal fakeroot-tcp behaviour on sid
+ <braunr> pinotree: a faked-tcp that is started for each command invocation
+ will implicitely make the network stack close all its sockets when
+ exiting
+ <braunr> pinotree: as our fakeroot-tcp uses the same instance of faked-tcp,
+ it's a lot more likely to exhaust the port space
+ <pinotree> i see
+ <braunr> i'll try on sid and see how it behaves
+ <braunr> pinotree: on the other hand, forking so many processes at each
+ command invocation may make exec leak a lot :p
+ <braunr> or rather, a lot more
+ <braunr> (or maybe not, since it leaks only in some cases)
+
+[[exec_memory_leaks]].
+
+ <braunr> pinotree: actually, the behaviour under linux is the same with the
+ alternative correctly set, whereas faked-tcp is restarted (if used at
+ all) with -rfakeroot-tcp
+ <braunr> hm no, even that isn't true
+ <braunr> grr
+ <braunr> pinotree: i think i found a handy workaround for fakeroot
+ <braunr> pinotree: the range of local ports in our networking stack is a
+ lot more limited than what is configured in current systems
+ <braunr> by extending it, i can now build glibc \o/
+ <pinotree> braunr: what are the current ours and the usual one?
+ <braunr> see pfinet/linux-src/net/ipv4/tcp_ipv4.c
+ <braunr> the modern ones are the ones suggested in the comment
+ <braunr> sysctl_local_port_range is the symbol storing the range
+ <pinotree> i see
+ <pinotree> what's the current range on linux?
+ <braunr> 20:44 < braunr> the modern ones are the ones suggested in the
+ comment
+ <pinotree> i see
+ <braunr> $ cat /proc/sys/net/ipv4/ip_local_port_range
+ <braunr> 32768 61000
+ <braunr> so, i'm not sure why we have the problem, since even on linux,
+ netstat doesn't show open bound ports, but it does help
+ <braunr> the fact faked-tcp can remain after its use is more problematic
+ <pinotree> (maybe pfinet could grow a (startup-only?) option to change it,
+ similar to that sysctl)
+ <braunr> but it can also stems from the same issue gnu_srs found about
+ closed sockets that haven't been shut down
+ <braunr> perhaps
+ <braunr> but i don't see the point actually
+ <braunr> we could simply change the values in the code
+
+ <braunr> youpi: first, in pfinet, i increased the range of local ports to
+ reduce the likeliness of port space exhaustion
+ <braunr> so we should get a lot less EAGAIN after that
+ <braunr> (i've not committed any of those changes)
+ <youpi> range of local ports?
+ <braunr> see pfinet/linux-src/net/ipv4/tcp_ipv4.c, tcp_v4_get_port function
+ and sysctl_local_port_range array
+ <youpi> oh
+ <braunr> EAGAIN is caused by tcp_v4_get_port failing at
+ <braunr> /* Exhausted local port range during search? */
+ <braunr> if (remaining <= 0)
+ <braunr> goto fail;
+ <youpi> interesting
+ <youpi> so it's not a hurd bug after all
+ <youpi> just a problem in fakeroot eating a lot of ports
+ <braunr> maybe because of the same issue gnu_srs worked on (bad socket
+ close when no clean shutdown)
+ <braunr> maybe, maybe not
+ <braunr> but increasing the range is effective
+ <braunr> and i compared with what linux does today, which is exactly what
+ is in the comment above sysctl_local_port_range
+ <braunr> so it looks safe
+ <youpi> so that means that the pfinet just uses ports 1024- 4999 for
+ auto-allocated ports?
+ <braunr> i guess so
+ <youpi> the linux pfinet I meant
+ <braunr> i haven't checked the whole code but it looks that way
+ <youpi> ./sysctl_net_ipv4.c:static int ip_local_port_range_min[] = { 1, 1
+ };
+ <youpi> ./sysctl_net_ipv4.c:static int ip_local_port_range_max[] = { 65535,
+ 65535 };
+ <youpi> looks like they have increased it since then :)
+ <braunr> hum :)
+ <braunr> $ cat /proc/sys/net/ipv4/ip_local_port_range
+ <braunr> 32768 61000
+ <youpi> yep, same here
+ <youpi> ./inet_connection_sock.c: .range = { 32768, 61000 },
+ <youpi> so there are two things apparently
+ <youpi> but linux now defaults to 32k-61k
+ <youpi> braunr: please just push the port range upgrade to 32Ki-61K
+ <braunr> ok, will do
+ <youpi> there's not reason not to do it
+
+
+## IRC, freenode, #hurd, 2012-12-11
+
+ <braunr> youpi: at least, i haven't had any failure building eglibc since
+ the port range patch
+ <youpi> good :)
diff --git a/open_issues/fakeroot_exit_0.mdwn b/open_issues/fakeroot_exit_0.mdwn
new file mode 100644
index 00000000..c6075b17
--- /dev/null
+++ b/open_issues/fakeroot_exit_0.mdwn
@@ -0,0 +1,35 @@
+[[!meta copyright="Copyright © 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]]."]]"""]]
+
+ $ fakeroot ./scripts/mkinstalldirs /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/debian/tmp-libc/usr/include
+ [...]
+ + LD_LIBRARY_PATH=/usr/lib/libfakeroot:/usr/lib64/libfakeroot:/usr/lib32/libfakeroot
+ + LD_PRELOAD=libfakeroot-tcp.so
+ + ./scripts/mkinstalldirs /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/debian/tmp-libc/usr/include
+ libfakeroot: connect: Interrupted system call
+ + RESULT=0
+
+ exit $RESULT
+ + exit 0
+ kill -s HUP 23612
+ + kill -s HUP 23612
+
+(The `EINTR` issue has been [[!debbug desc="fixed" 641200]].)
+
+`connect() < 0` invokes `fail()` which invokes `exit(1)`. Not yet figured out
+why the process exits 0 dispite that. `LD_PRELOAD` issue? ([[!taglink
+open_issue_glibc]].)
+
+
+# Build
+
+`libacl1-dev` is missing.
+
+ $ DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -uc -b -d
diff --git a/open_issues/fcntl_F_SETFL_FD.mdwn b/open_issues/fcntl_F_SETFL_FD.mdwn
new file mode 100644
index 00000000..4d270250
--- /dev/null
+++ b/open_issues/fcntl_F_SETFL_FD.mdwn
@@ -0,0 +1,26 @@
+[[!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]]."]]"""]]
+
+[[!meta title="fcntl.*F_SETFL.*FD_.*"]]
+
+[[!tag open_issue_porting]]
+
+
+# IRC, OFTC, #debian-hurd, 2012-12-16
+
+ <pinotree> http://lists.debian.org/<50CE505F.3040106@pyro.eu.org>
+ <pinotree> or http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679198#123
+ too
+ <youpi> ouch, there are quite a few!
+ <pinotree> most are "duplicated", like the source in webkit2 copies (so
+ fixing it once upstream will make it fixed progressively once the copies
+ are upgraded)
+ <youpi> ah, ok
+ <pinotree> similar for ruby 1.8/1.9/jruby
diff --git a/open_issues/fcntl_locking_dev_null.mdwn b/open_issues/fcntl_locking_dev_null.mdwn
new file mode 100644
index 00000000..4c65a5c4
--- /dev/null
+++ b/open_issues/fcntl_locking_dev_null.mdwn
@@ -0,0 +1,38 @@
+[[!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]]."]]"""]]
+
+[[!meta title="fcntl locking /dev/null"]]
+
+[[!tag open_issue_hurd]]
+
+
+# IRC, OFTC, #debian-hurd, 2012-07-06
+
+ <pinotree> regarding the libwibble failure (which holds libbuffy →
+ libbuffy-bindings), the failing test happens because it logs to /dev/null
+ as test file,
+ <pinotree> and while doing that, it wants to lock it first, having a
+ ENOTSUP in return
+ <youpi> oh
+ <youpi> locking null, how interesting
+ <youpi> what is that supposed to do ? :o)
+ <pinotree> from what i was reading posix, it would seem that such object is
+ considered a "File"
+ <youpi> is it our unimplemented record lock, or just the lock operation
+ that /dev/null doesn't support ?
+ <youpi> what size is null supposed to be? zero, right?
+ <pinotree> the latter
+ <youpi> ah
+ <youpi> so we can simply make lock return 0
+ <youpi> since there's no byte to lock?
+ <youpi> I don't remember whether you can lock unexistant bytes
+ <pinotree> indeed, if i change the libwibble unit test to use eg /tmp/foo,
+ they pas
+ <pinotree> s
diff --git a/open_issues/fdisk.mdwn b/open_issues/fdisk.mdwn
new file mode 100644
index 00000000..ece8fc89
--- /dev/null
+++ b/open_issues/fdisk.mdwn
@@ -0,0 +1,19 @@
+[[!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]]."]]"""]]
+
+ Command (m for help): w
+ The partition table has been altered!
+
+ Calling ioctl() to re-read partition table.
+ *Segmentation fault*
+
+Changes have been saved, though.
+
+Perhaps realted to the [[BLKRRPART_IOCTL]]?
diff --git a/open_issues/fifo_O_RDWR.mdwn b/open_issues/fifo_O_RDWR.mdwn
new file mode 100644
index 00000000..730e5c6f
--- /dev/null
+++ b/open_issues/fifo_O_RDWR.mdwn
@@ -0,0 +1,25 @@
+[[!meta copyright="Copyright © 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]]."]]"""]]
+
+[[!meta title="fifo O_RDWR"]]
+
+[[!tag open_issue_hurd]]
+
+[[!debbug 646016]]
+
+IRC, OFTC, #debian-hurd, 2011-10-19:
+
+ <tschwinge> pinotree: Nice! And that open(FIFO, O_RDWR) hanging issue may
+ warrant investigation on the Hurd side, too -- if the other systems
+ behave differently, we should probably have convincing reasons for our
+ behavior.
+ <pinotree> i gue somebody working on hurd never cared about that case - i
+ guess it falls back to one of O_RDONLY or O_WRONLY
+ <pinotree> *guess
diff --git a/open_issues/fifo_thread_explosion.mdwn b/open_issues/fifo_thread_explosion.mdwn
new file mode 100644
index 00000000..08f682f2
--- /dev/null
+++ b/open_issues/fifo_thread_explosion.mdwn
@@ -0,0 +1,20 @@
+[[!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_hurd]]
+
+As reported in [[!message-id "87sj80yb3e.fsf@kepler.schwinge.homeip.net"]],
+after a [[GCC]] build (native, so three stages bootstrap), we got:
+
+ PID UID PPID PGrp Sess TH Vmem RSS %CPU User System Args
+ 449 1000 3 1 1 10118 782M 198M 0.0 0:40.78 2:26.65 /hurd/fifo
+
+The other processes, in particular two instances of ext2fs and one of [[exec]],
+looked reasonable.
diff --git a/open_issues/file_locking.mdwn b/open_issues/file_locking.mdwn
new file mode 100644
index 00000000..7dfbdb94
--- /dev/null
+++ b/open_issues/file_locking.mdwn
@@ -0,0 +1,98 @@
+[[!meta copyright="Copyright © 2010, 2011, 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]]."]]"""]]
+
+[[!tag open_issue_hurd open_issue_glibc]]
+
+[[!toc]]
+
+
+# Google Summer of Code Project Idea
+
+[[community/gsoc/project_ideas/File_Locking]].
+
+
+# visudo
+
+[[visudo]].
+
+
+# Existing Work
+
+[[!GNU_Savannah_patch 332]].
+
+
+# IRC, freenode, #hurd, 2010-12-31
+
+ <pinotree> youpi: i found the issue with python-apt
+ <pinotree> s/with/of/
+ <youpi> good!
+ <pinotree> lock file issue, though :/
+ <youpi> :/
+ <pinotree> this is the sample test case, derived from apt's code:
+ http://paste.debian.net/103536/
+ <pinotree> basically, it seems asking for a file lock in the same process
+ where there's already such lock on the file, fails
+ <pinotree> youpi: ↑
+ <youpi> uh, posix doesn't even define some nesting
+ <pinotree> it seems it just talks about concurrency with other processes
+ <youpi> posix tells more about it later
+ <youpi> saying that if a lock already exists, then it is replaced by the
+ new
+ <youpi> (when inside the same process)
+ <pinotree> yay, found a bug in hurd :p
+ <youpi> well, actually it's known
+ <youpi> i.e. setlk is completely bogus, based on flock
+ <youpi> and flock doesn't have the same semantic in that regard
+ <youpi> so we can't fix it without really implementing setlk
+ <pinotree> the XXX comment in glibc/sysdeps/mach/hurd/fcntl.c, by chance?
+ :)
+ <youpi> of course :)
+ <pinotree> youpi: hm, flock's man page says:
+ <pinotree> "A process may only hold one type of lock (shared or exclusive)
+ on a file. Subsequent flock() calls on an already locked file will
+ convert an existing lock to the new lock mode."
+ <pinotree> so a new lock in the same process over the original lock should
+ replace the old one?
+ <youpi> uh, that's not what I had seen
+ <pinotree> http://linux.die.net/man/2/flock
+ <youpi> An attempt to lock the file using one of these file descrip-
+ <youpi> tors may be denied by a lock that the calling process
+ has already
+ <youpi> placed via another descriptor.
+ <youpi> so it's really not that easy
+ <pinotree> that's in case of trying to create a lock on a file with a
+ different fd than the existing lock
+ <youpi> that's what your testcase does
+ <pinotree> which, hm, is python-apt's case
+ <youpi> that being said, the sentence I pasted does not seem to appear in
+ posix
+ <pinotree> flock() does not seem posix
+ <youpi> it may have been the behavior of Linux at some point in the past
+ <youpi> it's not , but F_SETLK is
+ <youpi> and in linux world, flock <=> F_SETLK, iirc
+ <youpi> in glibc world, even
+ <youpi> (just checked it, see sysdeps/posix/flock.c
+ <youpi> pinotree: I guess your testcase works on Linux?
+ <pinotree> which means we should get a proper F_SETLK working, and then
+ just use this flock version (instead of the custom one), no?
+ <pinotree> yes, it works on linux (and on kfreebsd, see that python-apt
+ builds)
+ <youpi> no, I mean our flock() should probably be happy with locking part
+ of a file several times
+ <youpi> (that is, hurd's file_lock() RPC)
+ <youpi> ah, no, on Linux flock is its own system call
+ <youpi> (which is independant from lockf from the locking point of view,
+ iirc)
+
+
+# 2014-03-11
+
+[[!message-id "1394523876.28244.11.camel@workhorse-peter-baumgarten-com"]].
diff --git a/open_issues/file_system_exerciser.mdwn b/open_issues/file_system_exerciser.mdwn
new file mode 100644
index 00000000..f8cca6a1
--- /dev/null
+++ b/open_issues/file_system_exerciser.mdwn
@@ -0,0 +1,31 @@
+[[!meta copyright="Copyright © 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_hurd]]
+
+Test our file system implementations with the [File System
+Exerciser](http://codemonkey.org.uk/projects/fsx/). See [[tmpfs
+discussion|hurd/translator/tmpfs/discussion]], and on [[Maksym_Planeta]].
+
+
+# Alternatives
+
+## fs_mark
+
+### IRC, freenode, #hurd, 2012-04-30
+
+ <pinotree> mcsim: http://sourceforge.net/projects/fsmark/
+ <pinotree> mcsim: just saw it in debian's NEW queue and from the
+ description it seemed like something it could be helpful for you
+ <pinotree> (and in general to test fs'es)
+
+
+## [[VFAT_Test_Suite]]
diff --git a/open_issues/fork_deadlock.mdwn b/open_issues/fork_deadlock.mdwn
new file mode 100644
index 00000000..08e53330
--- /dev/null
+++ b/open_issues/fork_deadlock.mdwn
@@ -0,0 +1,3566 @@
+[[!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]]
+
+This started appearing when Jérémie's [[glibc]] signal patches were integrated:
+very sporadically, but still now and then, `fork` will hang, as follows, and
+typically in `/bin/sh`.
+
+# I
+
+ depbase=`echo ptr_chck.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
+ /bin/dash ./libtool --tag=CC --mode=compile [...]/gcc/xgcc [...] [...]/boehm-gc/ptr_chck.c &&\
+ mv -f $depbase.Tpo $depbase.Plo
+
+ PID UID PPID PGrp Sess TH Vmem RSS %CPU User System Args
+ 9754 1000 9746 1695 480 2 134M 1.35M 0.0 0:00.05 0:00.04 make AR_FLAGS=rc CC_FOR_BUILD=gcc-4.6 CFLAGS=[...]
+ 10174 1000 9754 1695 480 2 146M 876K 0.0 0:00.00 0:00.00 /bin/dash -c depbase=`echo ptr_chck.lo | sed [...]
+ 10175 1000 10174 1695 480 2 146M 608K 0.0 0:00.00 0:00.00 /bin/dash -c depbase=`echo ptr_chck.lo | sed [...]
+ 10177 1000 10175 1695 480 2 146M 204K 96.0 0:50.97 71min /bin/dash -c depbase=`echo ptr_chck.lo | sed [...]
+
+
+## 10174
+
+ Thread 2 (Thread 10174.2):
+ #0 0x0105b7cc in mach_msg_trap () at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
+ No locals.
+ #1 0x0105bfc9 in __mach_msg (msg=0x1221f90, option=3, send_size=32, rcv_size=4096, rcv_name=104, timeout=0, notify=0) at msg.c:110
+ ret = <optimized out>
+ #2 0x0105c6f9 in __mach_msg_server_timeout (demux=0x106cf00 <msgport_server>, max_size=4096, rcv_name=104, option=0, timeout=0)
+ at msgserver.c:151
+ request = 0x1222fa0
+ reply = 0x1221f90
+ mr = <optimized out>
+ __PRETTY_FUNCTION__ = "__mach_msg_server_timeout"
+ #3 0x0105c7cb in __mach_msg_server (demux=0x106cf00 <msgport_server>, max_size=4096, rcv_name=104) at msgserver.c:196
+ No locals.
+ #4 0x0106cecf in _hurd_msgport_receive () at msgportdemux.c:68
+ No locals.
+ #5 0x66688b92 in ?? ()
+ No symbol table info available.
+
+ Thread 1 (Thread 10174.1):
+ #0 0x01078a5c in _hurd_intr_rpc_msg_in_trap () at intr-msg.c:134
+ err = <optimized out>
+ err = <optimized out>
+ user_option = 3
+ user_timeout = 0
+ m = 0x1023f34
+ msgh_bits = 5395
+ remote_port = 110
+ msgid = 21001
+ __PRETTY_FUNCTION__ = "_hurd_intr_rpc_mach_msg"
+ #1 0x012091a5 in __io_read (io_object=110, data=0x1024840, dataCnt=0x1024844, offset=-1, amount=128)
+ at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/hurd/RPC_io_read.c:137
+ Mess = {In = {Head = {msgh_bits = 5395, msgh_size = 0, msgh_remote_port = 110, msgh_local_port = 107, msgh_seqno = 0,
+ msgh_id = 21001}, offsetType = {msgt_name = 11, msgt_size = 64, msgt_number = 1, msgt_inline = 1, msgt_longform = 0,
+ msgt_deallocate = 0, msgt_unused = 0}, offset = -1, amountType = {msgt_name = 2, msgt_size = 32, msgt_number = 1,
+ msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, amount = 128}, Out = {Head = {msgh_bits = 5395,
+ msgh_size = 0, msgh_remote_port = 110, msgh_local_port = 107, msgh_seqno = 0, msgh_id = 21001}, RetCodeType = {msgt_name = 11,
+ msgt_size = 64, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, RetCode = -1,
+ dataType = {msgtl_header = {msgt_name = 255, msgt_size = 255, msgt_number = 4095, msgt_inline = 1, msgt_longform = 1,
+ msgt_deallocate = 1, msgt_unused = 1}, msgtl_name = 8194, msgtl_size = 4097, msgtl_number = 128},
+ data = '\000' <repeats 812 times>, "\021 \001\020o\000\000\000\364O\035\001\000\000\000\000\300B\002\001\070<\006\001\030\000\000\000/H\002\001\000\000\000\000\000\000\000\000TC\002\001XC\002\001\224G\002\001\020C\002\001\275\340\005\001\030\000\000\000p\337\005\001\224G\002\001XC\002\001\001", '\000' <repeats 11 times>, " W \001\030\000\000\000\271\314B\002\001\351\n\002\004\000\000\000\\\244!\001\220K\b\001\000\000\000\000\364O\035\001dG\002\001\b\240!\001pG\002\001\336>\006\001p\337\005\001\020\306\a\001 W \001\001\000\000\000XC\002\001\000\000\000\000\000\000\000\000\224G\002\001\000\000\000\000\000\000\000\000\224G\002\001\000\000\000\000\000\000\000\000/H\002\001 W \001\001", '\000' <repeats 403 times>"\330"...}}
+ msg_result = <optimized out>
+ msgh_size = <optimized out>
+ #2 0x0107d321 in readfd (port=110) at fd-read.c:34
+ nbytes = 0x0
+ nread = 0
+ data = 0x0
+ offset = 0
+ #3 0x01083880 in _hurd_ctty_input (port=110, ctty=0, rpc=0x102484c) at ctty-input.c:32
+ err = <optimized out>
+ #4 0x0107cd44 in _hurd_fd_read (fd=0x1218e88, buf=0x1024914, offset=-1) at fd-read.c:39
+ __ulink = {resource = {next = 0x0, prevp = 0x1218e8c}, thread = {next = 0x0, prevp = 0x121a45c},
+ cleanup = 0x1084b90 <_hurd_port_cleanup>, cleanup_data = 0x6e}
+ __ctty_ulink = {resource = {next = 0x1024880, prevp = 0x107c794}, thread = {next = 0x121a008, prevp = 0x70}, cleanup = 0x10471c4,
+ cleanup_data = 0x102db28}
+ ctty = 0
+ crit = <optimized out>
+ __result = 16927684
+ port = 110
+ err = <optimized out>
+ data = 0x1024914 "\004"
+ nbytes = 0x10248e8
+ nread = 128
+ #5 0x01141652 in __libc_read (fd=3, buf=0x1024914, nbytes=128) at ../sysdeps/mach/hurd/read.c:27
+ descriptor = <error reading variable descriptor (DWARF-2 expression error: DW_OP_reg operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.)>
+ err = <optimized out>
+ #6 0x0804f53b in ?? ()
+ No symbol table info available.
+ #7 0x0804f772 in ?? ()
+ No symbol table info available.
+ #8 0x0804c26c in ?? ()
+ No symbol table info available.
+ #9 0x0804b589 in ?? ()
+ No symbol table info available.
+ #10 0x0804b61e in ?? ()
+ No symbol table info available.
+ #11 0x0804bf31 in ?? ()
+ No symbol table info available.
+ #12 0x08049b3f in ?? ()
+ No symbol table info available.
+ #13 0x0108666b in __libc_start_main (main=0x8049a90, argc=3, ubp_av=0x1024bb4, init=0x80597b0, fini=0x80597a0, rtld_fini=0xf5c0,
+ stack_end=0x1024bac) at libc-start.c:257
+ result = <optimized out>
+ #14 0x08049c95 in ?? ()
+ No symbol table info available.
+
+
+## 10175
+
+ Thread 2 (Thread 10175.2):
+ #0 0x0105b7cc in mach_msg_trap () at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
+ No locals.
+ #1 0x0105bfc9 in __mach_msg (msg=0x1221f90, option=3, send_size=32, rcv_size=4096, rcv_name=104, timeout=0, notify=0) at msg.c:110
+ ret = <optimized out>
+ #2 0x0105c6f9 in __mach_msg_server_timeout (demux=0x106cf00 <msgport_server>, max_size=4096, rcv_name=104, option=0, timeout=0)
+ at msgserver.c:151
+ request = 0x1222fa0
+ reply = 0x1221f90
+ mr = <optimized out>
+ __PRETTY_FUNCTION__ = "__mach_msg_server_timeout"
+ #3 0x0105c7cb in __mach_msg_server (demux=0x106cf00 <msgport_server>, max_size=4096, rcv_name=104) at msgserver.c:196
+ No locals.
+ #4 0x0106cecf in _hurd_msgport_receive () at msgportdemux.c:68
+ No locals.
+ #5 0x66688b92 in ?? ()
+ No symbol table info available.
+ #6 0x00000000 in ?? ()
+ No symbol table info available.
+
+ Thread 1 (Thread 10175.1):
+ #0 0x01078a5c in _hurd_intr_rpc_msg_in_trap () at intr-msg.c:134
+ err = <optimized out>
+ err = <optimized out>
+ user_option = 3
+ user_timeout = 0
+ m = 0x1024638
+ msgh_bits = 5395
+ remote_port = 27
+ msgid = 24020
+ __PRETTY_FUNCTION__ = "_hurd_intr_rpc_mach_msg"
+ #1 0x011f99df in __proc_wait (process=27, pid=-1, options=0, status=0x10247f4, sigcode=0x102476c, rusage=0x1024708, pid_status=0x1024770)
+ at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/hurd/RPC_proc_wait.c:182
+ Mess = {In = {Head = {msgh_bits = 5395, msgh_size = 132, msgh_remote_port = 27, msgh_local_port = 107, msgh_seqno = 0,
+ msgh_id = 24020}, pidType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0,
+ msgt_deallocate = 0, msgt_unused = 0}, pid = -1, optionsType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1,
+ msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, options = 0}, Out = {Head = {msgh_bits = 5395, msgh_size = 132,
+ msgh_remote_port = 27, msgh_local_port = 107, msgh_seqno = 0, msgh_id = 24020}, RetCodeType = {msgt_name = 2, msgt_size = 32,
+ msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, RetCode = -1, statusType = {
+ msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0},
+ status = 0, sigcodeType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0,
+ msgt_deallocate = 0, msgt_unused = 0}, sigcode = 0, rusageType = {msgt_name = 2, msgt_size = 32, msgt_number = 18,
+ msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, rusage = {ru_utime = {tv_sec = 0, tv_usec = 0},
+ ru_stime = {tv_sec = 0, tv_usec = 0}, ru_maxrss = 0, ru_ixrss = 0, ru_idrss = 0, ru_isrss = 0, ru_minflt = 0, ru_majflt = 0,
+ ru_nswap = 0, ru_inblock = 0, ru_oublock = 0, ru_msgsnd = 0, ru_msgrcv = 0, ru_nsignals = 0, ru_nvcsw = 0, ru_nivcsw = 0},
+ pid_statusType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_lo