From 5a7f0df43751e45c1219fa1213f9abc69eb918cf Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 20 Aug 2008 16:35:44 +0200 Subject: hurd/io_path: Rework completely. --- hurd/io_path.mdwn | 71 ++++++++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 62 insertions(+), 9 deletions(-) (limited to 'hurd') diff --git a/hurd/io_path.mdwn b/hurd/io_path.mdwn index 96e6aa58..b55dc20f 100644 --- a/hurd/io_path.mdwn +++ b/hurd/io_path.mdwn @@ -10,18 +10,71 @@ is included in the section entitled # read - * [[glibc]]'s `read` is in `glibc/sysdeps/mach/hurd/read.c:__libc_read`. +[[glibc]]'s `read` is in `glibc/sysdeps/mach/hurd/read.c:__libc_read`. - * That calls `glibc/hurd/fd-read.c:_hurd_fd_read()`. +A buffer (and its size) to store the to-be-read data in is supplied by the +caller of `read`. - * That calls `__io_read`, which is an [[RPC]], i.e., that actually results - into the [[translator/ext2fs]] server calling - `hurd/libdiskfs/io-read.c:diskfs_S_io_read`. +> `__libc_read` calls `glibc/hurd/fd-read.c:_hurd_fd_read`. - * That calls `_diskfs_rdwr_internal`, which calls - `hurd/libpager/pager-memcpy.c:pager_memcpy`, which usually basically just - tell the kernel to virtually project the memory object corresponding to the - file in the caller process's memory. No read is actually done. +>> `_hurd_fd_read` calls `__io_read`, which is an [[RPC]]: +>> `hurd/hurd/io.defs:io_read`. + +>>> Enter user-side RPC stub `glibc.obj/hurd/RPC_io_read.c:__io_read`. Process +>>> stuff, switch to kernel, etc. + +(For example) [[translator/hello]] server, [[libtrivfs]]-based. Enter +server-side RPC stub `hurd.obj/libtrivfs/ioServer.c:_Xio_read`. Process stuff, +call `hurd/trans/hello.c:trivfs_S_io_read`. + +A 2048 byte buffer is provided. + +> `trivfs_S_io_read`. Depending on the internatl state, either a new memory +> region is set-up (and returned as out-of-line data), or the desired amount of +> data is returned in-line. + +Back in `_Xio_read`. + +If the 2048 byte buffer is not decided to be used (out-of-line case or bigger +than 2048 bytes case; server decides to instead provide a new memory region), +the [[`dealloc`|microkernel/mach/mig/dealloc]] flag is being set, which causes +Mach to unmap that memory region from the server's address space, i.e., doing a +memory *move* from the server to the client. + +Leave server-side RPC stub `_Xio_read`. + +>>> Return from kernel, continue client-side RPC stub `io_read`. Have to copy +>>> data. Three cases: out-of-line data (pass pointer to memory area); +>>> returned more data than fits into the originally supplied buffer (allocate +>>> new buffer, copy all data into it, pass pointer of new buffer); otherwise +>>> copy as much data as is available into the originally supplied buffer. +>>> I.e., in all cases *all* data which was provided by the server is made +>>> available to the caller. + +>> Back in `_hurd_fd_read`. If a new buffer has been allocated previously, or +>> the out-of-line mechanism has been used, the returned data now has to be +>> copied into the originally supplied buffer. If the server returned more +>> data than requested, this is a [[protocol_violation|EGRATUITOUS]]. + +> Back in `__libc_read`. + + +--- + +Samuel: + +(For example) [[translator/ext2fs]] server, enter server-side RPC stub +`hurd.obj/libdiskfs/ioServer.c:_Xio_read`. Process stuff, call +`hurd/libdiskfs/io-read.c:diskfs_S_io_read`. + +A 2048 byte buffer is provided. + +> `diskfs_S_io_read` calls `_diskfs_rdwr_internal`. + +>> That calls `hurd/libpager/pager-memcpy.c:pager_memcpy`, which usually +>> basically just tells the kernel to virtually project the memory object +>> corresponding to the file in the caller process's memory. No read is +>> actually done. * Then, when the process actually reads the data, the kernel gets the user page fault (`gnumach/i386/i386/trap.c:user_trap`), which calls `vm_fault`, -- cgit v1.3.1 From 088ca85671518ac9033904dae6444d7d532586d4 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Fri, 22 Jul 2011 09:41:11 +0200 Subject: IRC. --- hurd/translator/procfs/jkoenig/discussion.mdwn | 18 +++++++++++ .../gnumach_vm_map_entry_forward_merging.mdwn | 11 +++++++ open_issues/libpthread_dlopen.mdwn | 36 ++++++++++++++++++++++ 3 files changed, 65 insertions(+) create mode 100644 open_issues/libpthread_dlopen.mdwn (limited to 'hurd') diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn index b66af7de..64e3776e 100644 --- a/hurd/translator/procfs/jkoenig/discussion.mdwn +++ b/hurd/translator/procfs/jkoenig/discussion.mdwn @@ -166,3 +166,21 @@ IRC, freenode, #hurd, 2011-03-28 mentoring the previous procfs implementation (though I never got around to look at his buggy code...) ok + +IRC, freenode, #hurd, 2011-07-22 + + hm, why /proc/$pid/stat is 600 instead of 644 of linux? + pinotree, it reveals information which, while not that sensitive, + would not be available to users through the normal proc interface. + (it's available through the ps command which is setuid root) + we discussed at some point making it 644, IIRC. + hm, then why is it not a problem on eg linux? + (btw you can change it with the -s option.) + pinotree, it's not a problem because the information is not that + sensitive, but when rewriting procfs I preferred to play it self and + consider it's not procfs' job to decide what is sensitive or not. + IIRC it's not sensitive but you need the task port to query it. + like, thread times or something. + status is 644 though + but status contains information which anyone can ask to the proc + server anyway, I think. diff --git a/open_issues/gnumach_vm_map_entry_forward_merging.mdwn b/open_issues/gnumach_vm_map_entry_forward_merging.mdwn index b2b20c5b..f1c8bd6e 100644 --- a/open_issues/gnumach_vm_map_entry_forward_merging.mdwn +++ b/open_issues/gnumach_vm_map_entry_forward_merging.mdwn @@ -171,6 +171,17 @@ License|/fdl]]."]]"""]] entries) +# IRC, freenode, #hurd, 2011-07-21 + + tschwinge: you may remove the forward map entry merging issue :/ + what did you discover? + tschwinge: it's actually much more complicated than i thought, and + needs major changes in the vm, and about the way anonymous memory is + handled + from what i could see, part of the problem still exists in freebsd + for the same reasons (shadow objects being one of them) + + # Procedure * Analyze. diff --git a/open_issues/libpthread_dlopen.mdwn b/open_issues/libpthread_dlopen.mdwn new file mode 100644 index 00000000..f60c81a4 --- /dev/null +++ b/open_issues/libpthread_dlopen.mdwn @@ -0,0 +1,36 @@ +[[!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_libpthread]] + +IRC, OFTC, #debian-hurd, 2011-07-21. + + there's one known issue with pthreads + you can't dlopen() it + which also means you can't dlopen() a module which depends on it if + the main application hasn't used -lpthread already + (so as to get libpthread initialized early, not at the dlopen() + call) + I get this while building simgrid: + cd /home/lucas/simgrid-3.6.1/obj-i486-gnu/examples/gras/console && + /usr/bin/cmake -E create_symlink + /home/lucas/simgrid-3.6.1/obj-i486-gnu/lib/libsimgrid.so + /home/lucas/simgrid-3.6.1/obj-i486-gnu/examples/gras/console/simgrid.so + cd /home/lucas/simgrid-3.6.1/obj-i486-gnu/examples/gras/console && + lua /home/lucas/simgrid-3.6.1/examples/gras/console/ping_generator.lua + lua: + /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libpthread/sysdeps/generic/pt-mutex-timedlock.c:68: + __pthread_mutex_timedlock_internal: Assertion `__pthread_threads' failed. + Aborted (core dumped) + that's it, yes + (or at least it has the same symptoms) + it would need fixing in lua, not in SG, then, right? + yes + ok, thanks -- cgit v1.3.1 From 4f090e2d9898e8aa03247a041398e3058983023c Mon Sep 17 00:00:00 2001 From: antrik Date: Fri, 22 Jul 2011 22:51:23 +0200 Subject: documentation/translator_primer: Be clearer about the actual meaning of settrans -g... I hope this doesn't make it harder to follow. Considering the non-obvious option semantics of settrans, I think it's crucial for newcomers to get the meaning right from the very beginning! --- hurd/documentation/translator_primer.mdwn | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'hurd') diff --git a/hurd/documentation/translator_primer.mdwn b/hurd/documentation/translator_primer.mdwn index 4586a8e6..e5c8c160 100644 --- a/hurd/documentation/translator_primer.mdwn +++ b/hurd/documentation/translator_primer.mdwn @@ -41,7 +41,11 @@ Then you setup the translator /hurd/hello in the file/node hello. After that you check the contents of the file, and the translator returns "Hello World!". -To finish it, you tell the translator to go away from the file "hello" via "settrans -g hello" and verify that now the file is empty again. +To finish it, +you remove the translator from the file "hello" +(and tell any active running instances to go away) +via "settrans -g hello". +Having done that, verify that now the file is empty again. ### Transparent FTP -- cgit v1.3.1 From 6a2711d5e6896dfeb3d4d5342ec904dce1b22b77 Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Sat, 6 Aug 2011 13:07:56 +0200 Subject: 184565 was fixed --- hurd/porting/system_api_limitations.mdwn | 2 -- 1 file changed, 2 deletions(-) (limited to 'hurd') diff --git a/hurd/porting/system_api_limitations.mdwn b/hurd/porting/system_api_limitations.mdwn index 2fac456e..82327dde 100644 --- a/hurd/porting/system_api_limitations.mdwn +++ b/hurd/porting/system_api_limitations.mdwn @@ -22,8 +22,6 @@ These are the known system API limits that have porting implications. **_[\#47998](http://bugs.debian.org/47998): `msgget` IPC not implemented_** -**_[\#184565](http://bugs.debian.org/184565): libc0.3: missing shm\* functions (from ``)_**
**breaks:** cdrtools
**error:** warning: shm\* is not implemented and will always fail - **_[[nice() doesn't work|open_issues/nice_vs_mach_thread_priorities]]_**. **_[\#187391](http://bugs.debian.org/187391): libc0.3-dev: `sockaddr_un.sun_path` can't be assigned a `const char *` when compiling with g++_**
**breaks:** fam, gail
**status:** maybe this should be in [[PortingIssues]] (see _long_ bug log) -- cgit v1.3.1 From ba39ad0e85fbb60f65e21c1a4b9557bbddb3b8b4 Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Sat, 6 Aug 2011 13:16:04 +0200 Subject: Update --- hurd/running/debian/after_install.mdwn | 33 +++------------------------------ 1 file changed, 3 insertions(+), 30 deletions(-) (limited to 'hurd') diff --git a/hurd/running/debian/after_install.mdwn b/hurd/running/debian/after_install.mdwn index 62fd3574..36c37281 100644 --- a/hurd/running/debian/after_install.mdwn +++ b/hurd/running/debian/after_install.mdwn @@ -42,10 +42,10 @@ you. See [[GRUB]]'s page for this. # Setup `apt-get` Sometimes getting `apt-get` to work is not straightforward. Good mirrors to -put in `/etc/apt/sources.list` are (as of Jan 2007): +put in `/etc/apt/sources.list` are: - deb http://mirrors.kernel.org/debian unstable main contrib - deb-src http://mirrors.kernel.org/debian unstable main contrib + deb http://ftp.debian.org/debian unstable main contrib + deb-src http://ftp.debian.org/debian unstable main contrib deb http://ftp.debian-ports.org/debian unreleased main deb-src http://ftp.debian-ports.org/debian unreleased main @@ -75,38 +75,11 @@ You can also call the Hurd console manually with the proper arguments: console -d vga -d pc_kbd --repeat=kbd -d pc_mouse --repeat=mouse \ -d generic_speaker -c /dev/vcs - cd /dev - ln -s cons/kbd . - ln -s cons/mouse . - # [[Hurd/DebianXorg]] You first must have setup the virtual console. See above. -Assuming you've installed WindowMaker and have tried running `startx` already: - - [/etc/xorg.conf] - - Section "Module" - # Load "dri" - # Load "speedo" - . - . - . - EndSection - - Section "InputDevice" - Identifier "Configured Mouse" - Driver "mouse" - Option "CorePointer" - Option "Device" "/dev/mouse" - Option "Protocol" "osmouse" - EndSection - -Make sure not to have the `Emulate3Buttons` and `ZAxisMapping` settings set, as -they lead to problems with e.g. dragging windows around. - # What about package XYZ? See if you can find a useful tip in [[package_troubleshooting]]. -- cgit v1.3.1 From 9e404235a8aa9a44c8ecde7fc82aac3616d00aa1 Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Thu, 18 Aug 2011 00:23:34 +0200 Subject: mention sys/soundcard.h instead of linux/soundcard.h --- hurd/porting/guidelines.mdwn | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'hurd') diff --git a/hurd/porting/guidelines.mdwn b/hurd/porting/guidelines.mdwn index 8b7dcf02..fc71aa7c 100644 --- a/hurd/porting/guidelines.mdwn +++ b/hurd/porting/guidelines.mdwn @@ -279,9 +279,9 @@ With Python, you can use the [`errno` module](http://docs.python.org/library/err err.errno == errno.ENOENT: ... -## Missing `linux/types.h`, `asm/types.h`, `linux/limits.h`, `asm/byteorder.h`, `sys/endian.h`, `asm/ioctl.h`, `asm/ioctls.h` +## Missing `linux/types.h`, `asm/types.h`, `linux/limits.h`, `asm/byteorder.h`, `sys/endian.h`, `asm/ioctl.h`, `asm/ioctls.h`, `linux/soundcard.h` -These are often used (from lame rgrep results) instead of their standard equivalents: `sys/types.h` (or `stdint.h` for fixed-size types), `limits.h`, `endian.h`, `sys/ioctl.h`. +These are often used (from lame rgrep results) instead of their standard equivalents: `sys/types.h` (or `stdint.h` for fixed-size types), `limits.h`, `endian.h`, `sys/ioctl.h`, `sys/soundcard.h` ## Missing `sys/*.h`, `linux/*.h` -- cgit v1.3.1 From 14a6ee07dae44039db18aa41a089453b132871f1 Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Thu, 18 Aug 2011 01:26:47 +0200 Subject: talk about libdl hardcoding --- hurd/porting/guidelines.mdwn | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'hurd') diff --git a/hurd/porting/guidelines.mdwn b/hurd/porting/guidelines.mdwn index fc71aa7c..8f21a64f 100644 --- a/hurd/porting/guidelines.mdwn +++ b/hurd/porting/guidelines.mdwn @@ -279,6 +279,10 @@ With Python, you can use the [`errno` module](http://docs.python.org/library/err err.errno == errno.ENOENT: ... +## undefined reference to `dlopen`, `dlsym`, `dlclose` + +Configure script often hardcode the library that contains dlopen & such (`-ldl'), and only for Linux. Simply add the other GNU OS cases: replace `linux*' with `linux*|gnu*|k*bsd*-gnu` + ## Missing `linux/types.h`, `asm/types.h`, `linux/limits.h`, `asm/byteorder.h`, `sys/endian.h`, `asm/ioctl.h`, `asm/ioctls.h`, `linux/soundcard.h` These are often used (from lame rgrep results) instead of their standard equivalents: `sys/types.h` (or `stdint.h` for fixed-size types), `limits.h`, `endian.h`, `sys/ioctl.h`, `sys/soundcard.h` -- cgit v1.3.1 From b9312fdda06a0ad836b203759a090ebfe458a63b Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Fri, 19 Aug 2011 14:50:01 +0200 Subject: recommend to add X-Debbugs-CC --- hurd/running/debian/patch_submission.mdwn | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'hurd') diff --git a/hurd/running/debian/patch_submission.mdwn b/hurd/running/debian/patch_submission.mdwn index 66348dd9..d2d10747 100644 --- a/hurd/running/debian/patch_submission.mdwn +++ b/hurd/running/debian/patch_submission.mdwn @@ -36,6 +36,12 @@ follow these guidelines: * `User: debian-hurd@lists.debian.org` * `Usertags: hurd` +Please also add + +`X-Debbugs-CC: debian-hurd@lists.debian.org` + +in the mail headers, so that the mailing list knows about your report. + In the bug description, mention that the package fails to build on hurd-i386 and (if possible) quote the failure. If possible, point to the failing build log from or elsewhere. -- cgit v1.3.1 From 088a7c18c83ecbab78e92dc051630ae92f5ed5e7 Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Mon, 22 Aug 2011 01:41:52 +0200 Subject: DHCP is now working. --- hurd/translator/pfinet/dhcp.mdwn | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'hurd') diff --git a/hurd/translator/pfinet/dhcp.mdwn b/hurd/translator/pfinet/dhcp.mdwn index 17776fa5..79ed8966 100644 --- a/hurd/translator/pfinet/dhcp.mdwn +++ b/hurd/translator/pfinet/dhcp.mdwn @@ -6,6 +6,10 @@ According to the following thread, no port should be needed since all the patche The thread starts at Jan 4th 2005 until Jan 6th and is only retaken at April 14th in [this thread](http://lists.gnu.org/archive/html/bug-hurd/2005-01/msg00025.html). +-- 2011 + +The ISC dhcp client was ported, available in the isc-dhcp-client Debian package, [[http://bugs.debian.org/616290]]. + -- [[Main/ThadeuCascardo]] - 29 Sep 2005 No DHCP client has been ported to the Hurd yet. -- cgit v1.3.1 From b62db0d2e9f8311c74d2de7439ea5ea07bfe8272 Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Thu, 25 Aug 2011 10:44:26 +0200 Subject: Document autoconf host_os tests --- hurd/porting/guidelines.mdwn | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) (limited to 'hurd') diff --git a/hurd/porting/guidelines.mdwn b/hurd/porting/guidelines.mdwn index 8f21a64f..0a9c133a 100644 --- a/hurd/porting/guidelines.mdwn +++ b/hurd/porting/guidelines.mdwn @@ -23,6 +23,29 @@ You may ask on the [[mailing lists/bug-hurd]] mailing list for details or questions about fixing bugs. +## Fixing configure.ac/in + +The GNU/Hurd (and GNU/kFreeBSD) toolchain is extremely close to the GNU/Linux toolchain. +configure.ac thus very often just needs to be fixed by using the same cases as Linux, that is, turn + + switch "$host_os" in + case linux*) + +into + + switch "$host_os" in + case linux*|k*bsd-gnu|gnu*) + +for a host_os case statement, or + + switch "$host" in + case *-linux*) + +into + + switch "$host" in + case *-linux*|*-k*bsd-gnu|*-gnu*) + ## Undefined `bits/confname.h` macros (`PIPE_BUF`, ...) If macro `XXX` is undefined, but macro `_SC_XXX` or `_PC_XXX` is defined in `bits/confname.h`, you probably need to use `sysconf`, `pathconf` or `fpathconf` to obtain it dynamicaly. -- cgit v1.3.1 From 9e51b41b8834a8e9743bd4143ed253ade346423a Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Thu, 25 Aug 2011 15:06:36 +0200 Subject: comment on the order of *-linux* vs *-gnu* --- hurd/porting/guidelines.mdwn | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) (limited to 'hurd') diff --git a/hurd/porting/guidelines.mdwn b/hurd/porting/guidelines.mdwn index 0a9c133a..65fb6409 100644 --- a/hurd/porting/guidelines.mdwn +++ b/hurd/porting/guidelines.mdwn @@ -34,7 +34,7 @@ configure.ac thus very often just needs to be fixed by using the same cases as L into switch "$host_os" in - case linux*|k*bsd-gnu|gnu*) + case linux*|k*bsd-gnu*|gnu*) for a host_os case statement, or @@ -44,7 +44,18 @@ for a host_os case statement, or into switch "$host" in - case *-linux*|*-k*bsd-gnu|*-gnu*) + case *-linux*|*-k*bsd-gnu*|*-gnu*) + +If separate case is needed, make sure to put *-gnu* *after* *-linux*: + + switch "$host" in + case *-linux*|*-k*bsd-gnu*) + something;; + + case *-gnu*) + something else;; + +because else *-gnu* would catch i386-pc-linux-gnu for instance... ## Undefined `bits/confname.h` macros (`PIPE_BUF`, ...) -- cgit v1.3.1 From ccad4d6467bbbcc72022fc04fc0e8cf74849aba1 Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Fri, 26 Aug 2011 00:32:08 +0200 Subject: Mention configure stuff coming from libtool --- hurd/porting/guidelines.mdwn | 2 ++ 1 file changed, 2 insertions(+) (limited to 'hurd') diff --git a/hurd/porting/guidelines.mdwn b/hurd/porting/guidelines.mdwn index 65fb6409..c5dd4891 100644 --- a/hurd/porting/guidelines.mdwn +++ b/hurd/porting/guidelines.mdwn @@ -57,6 +57,8 @@ If separate case is needed, make sure to put *-gnu* *after* *-linux*: because else *-gnu* would catch i386-pc-linux-gnu for instance... +Note: some of such statements are not from the source package itself, but from aclocal.m4 which is actually from libtool. In such case, the package simply needs to be re-libtoolize-d. + ## Undefined `bits/confname.h` macros (`PIPE_BUF`, ...) If macro `XXX` is undefined, but macro `_SC_XXX` or `_PC_XXX` is defined in `bits/confname.h`, you probably need to use `sysconf`, `pathconf` or `fpathconf` to obtain it dynamicaly. -- cgit v1.3.1 From 016433b123ce4b60eee550dbdb7812ba623d16e7 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Tue, 30 Aug 2011 12:03:36 +0200 Subject: Minor tweaks. --- hurd/porting/system_api_limitations.mdwn | 2 +- hurd/running/debian/dhcp.mdwn | 7 +++ hurd/running/debian/patch_submission.mdwn | 7 +-- hurd/translator/pfinet/dhcp.mdwn | 37 ++++++-------- microkernel/mach/gnumach/building.mdwn | 11 +++++ microkernel/mach/gnumach/debugging.mdwn | 34 ++++++++----- microkernel/mach/mig/gnu_mig/building.mdwn | 11 +++++ .../mach/mig/gnu_mig/building/discussion.mdwn | 16 ++++++ microkernel/mach/mig/gnu_mig/discussion.mdwn | 6 --- open_issues/e2fsck_i_file_acl_hi.mdwn | 5 +- open_issues/libpthread_dlopen.mdwn | 14 +++--- open_issues/perl.mdwn | 13 ++--- open_issues/runit.mdwn | 57 +++++++++------------- open_issues/sync_but_still_unclean_filesystem.mdwn | 5 +- open_issues/virtualbox.mdwn | 30 ++++++------ source_repositories.mdwn | 17 ++++--- 16 files changed, 154 insertions(+), 118 deletions(-) create mode 100644 microkernel/mach/mig/gnu_mig/building/discussion.mdwn delete mode 100644 microkernel/mach/mig/gnu_mig/discussion.mdwn (limited to 'hurd') diff --git a/hurd/porting/system_api_limitations.mdwn b/hurd/porting/system_api_limitations.mdwn index 82327dde..1615ccc0 100644 --- a/hurd/porting/system_api_limitations.mdwn +++ b/hurd/porting/system_api_limitations.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2003, 2004, 2005, 2009, 2010 Free Software +[[!meta copyright="Copyright © 2003, 2004, 2005, 2009, 2010, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable diff --git a/hurd/running/debian/dhcp.mdwn b/hurd/running/debian/dhcp.mdwn index f316981d..8d351aae 100644 --- a/hurd/running/debian/dhcp.mdwn +++ b/hurd/running/debian/dhcp.mdwn @@ -22,3 +22,10 @@ fatal. Debian GNU/Hurd doesn't currently execute's Debian standard `/etc/rcS.d/*` boot scripts, but has its own `/libexec/rc` script -- which integrates scripts from `/etc/rc.boot/` instead. + + +# Open Issues + + * [[!debbug 616290]] + + * [[Proper Hurdy DHCP support|hurd/translator/pfinet/dhcp]] diff --git a/hurd/running/debian/patch_submission.mdwn b/hurd/running/debian/patch_submission.mdwn index d2d10747..d2b7b776 100644 --- a/hurd/running/debian/patch_submission.mdwn +++ b/hurd/running/debian/patch_submission.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] If you fixed a Debian package which *FTBFS* (fails to build from source), you should submit the patch so that all users can profit from your work. diff --git a/hurd/translator/pfinet/dhcp.mdwn b/hurd/translator/pfinet/dhcp.mdwn index 79ed8966..456d0c84 100644 --- a/hurd/translator/pfinet/dhcp.mdwn +++ b/hurd/translator/pfinet/dhcp.mdwn @@ -1,31 +1,33 @@ -[[!tag open_issue_hurd]] +[[!meta copyright="Copyright © 2002, 2003, 2005, 2011 Free Software Foundation, +Inc."]] -According to the following thread, no port should be needed since all the patches that have been applied, including the one concerning the thread. In fact, the thread finishes without concluding whether the patch has been applied or not. You can grab it in the thread, anyway. +[[!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]]."]]"""]] -[Link to thread](http://lists.gnu.org/archive/html/bug-hurd/2005-01/msg00025.html) +[[!tag open_issue_hurd]] -The thread starts at Jan 4th 2005 until Jan 6th and is only retaken at April 14th in [this thread](http://lists.gnu.org/archive/html/bug-hurd/2005-01/msg00025.html). +[[Debian GNU/Hurd|running/debian]] has some script hackery to get +[[running/debian/DHCP]] going. --- 2011 +--- -The ISC dhcp client was ported, available in the isc-dhcp-client Debian package, [[http://bugs.debian.org/616290]]. +According to the following thread, no port should be needed since all the patches that have been applied, including the one concerning the thread. In fact, the thread finishes without concluding whether the patch has been applied or not. You can grab it in the thread, anyway. --- [[Main/ThadeuCascardo]] - 29 Sep 2005 +[Link to thread](http://lists.gnu.org/archive/html/bug-hurd/2005-01/msg00025.html) -No DHCP client has been ported to the Hurd yet. +The thread starts at Jan 4th 2005 until Jan 6th and is only retaken at April 14th in [this thread](http://lists.gnu.org/archive/html/bug-hurd/2005-01/msg00025.html). [This](http://mail.gnu.org/archive/html/help-hurd/2003-10/msg00016.html) thread on help-hurd has a little more info on what's still needed for DHCP. --- [[Main/GregBuchholz]] - 09 Oct 2003 - Found this [message](http://mail.gnu.org/archive/html/bug-hurd/2003-08/msg00045.html) about DHCP capabilities in the Hurd encouraging. --- [[Main/GregBuchholz]] - 03 Sep 2003 - * Tom Hart began a [discussion ](http://mail.gnu.org/pipermail/help-hurd/2002-October/006643.html) of 14 posts in Oct 2002. --- [[Main/GrantBow]] - 20 Oct 2002 - The beginnings of a DHCP translator is available in the Hurd sources on Savannah: [hurd/trans/pump.c](http://savannah.gnu.org/cgi-bin/viewcvs/hurd/hurd/trans/pump.c?rev=1.3&content-type=text/vnd.viewcvs-markup) Unfortunately our current TCP/IP stack, the pfinet translator, lacks support for the AF\_PACKET interface as well as sending packets with an IP address of 0.0.0.0. @@ -42,10 +44,3 @@ Neal Walfield on bug-hurd replies: > Anyone else know the status of getting these compiled and functional? We need to be able to send to the DHCP server with ip address 0.0.0.0. - --- [[Main/JoachimNilsson]] - 12 Nov 2002 - ---- - -[[Debian GNU/Hurd|running/debian]] has some script hackery to get -[[running/debian/DHCP]] going. diff --git a/microkernel/mach/gnumach/building.mdwn b/microkernel/mach/gnumach/building.mdwn index 24a73608..afcfac74 100644 --- a/microkernel/mach/gnumach/building.mdwn +++ b/microkernel/mach/gnumach/building.mdwn @@ -1,3 +1,14 @@ +[[!meta copyright="Copyright © 2006, 2007, 2008, 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]]."]]"""]] + # Building [[GNU_Mach|gnumach]] from Source If you want to build the [[GNU_Mach|gnumach]] kernel yourself instead of just using a diff --git a/microkernel/mach/gnumach/debugging.mdwn b/microkernel/mach/gnumach/debugging.mdwn index 596e4da0..f657e7cc 100644 --- a/microkernel/mach/gnumach/debugging.mdwn +++ b/microkernel/mach/gnumach/debugging.mdwn @@ -9,7 +9,12 @@ 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 are some hints to debug with GNU Mach +Here are some hints to debug with GNU Mach. + +[[!toc levels=2]] + + +# Kernel Debugger Mach has a built-in kernel debugger. [Manual](http://www.gnu.org/software/hurd/gnumach-doc/Kernel-Debugger.html). @@ -20,27 +25,25 @@ Then, reproduce the issue again. If something like a kernel trap happens, you wi If you are running in kvm or qemu, it is convenient to use the curses frontend to be able to copy/paste. -The debugger has an extensive documentation on http://www.gnu.org/software/hurd/gnumach-doc/Kernel-Debugger.html , but a quick start is the following. - To get the register values, type -show registers + show registers To get a backtrace, type trace, which will print both function return addresses and function parameters, such as -0x107cf1(8088488,5e,40000008,2aa008,0) -0x1071bc(0,0,0,0,0) -0x106831(24fe00,2000,b,800,0) + 0x107cf1(8088488,5e,40000008,2aa008,0) + 0x1071bc(0,0,0,0,0) + 0x106831(24fe00,2000,b,800,0) Run the addr2line tool on the return addresses: -addr2line -i -f -e /boot/gnumach 0x107cf1 0x1071bc 0x106831 + $ addr2line -i -f -e /boot/gnumach 0x107cf1 0x1071bc 0x106831 This will print the source code lines of the backtrace. To examine the backtrace of some given thread, use -show all thread/u + show all thread/u to get the whole listing of all tasks and threads. You can then use trace/t to trace a specific thread. @@ -48,25 +51,28 @@ Unfortunately, userland and kernelland use the same range of addresses, so one c To examine a variable, use nm /boot/gnumach to get the address of the variable (e.g. 0x123400), and use -x 0x123400 + x 0x123400 to read it. One can also write to it by using -w 0x123400 + w 0x123400 Another interesting feature is watching a variable, by using -watch 0x123400 + watch 0x123400 and then type continue, to let Mach continue execution. The debugger will be entered again on any change in that variable. The watch is implemented in hardware, so it does not disturb or slow down execution at all. +# GDB in QEMU When you're [[running_a_system_in_QEMU|hurd/running/qemu]] you can directly [use GDB on the running kernel](http://www.nongnu.org/qemu/qemu-doc.html#SEC48). +# Code Inside the Kernel + Alternatively you can use an approach like this one: add the following code snippet to `device/ds_routines.c`'s `ds_device_open` function, right at the top of the function, and modify the code as needed. @@ -105,6 +111,8 @@ This is especially useful if you need to manually trigger some stuff inside the running kernel, as with the *D1* example. +## Writing to the Screen Buffer + If you're doing real low level debugging, you might want to put variations of the following snipped into the code, this code will write a `#` character at line `[LINE]`, column `[COLUMN]` on the screen: @@ -118,6 +126,8 @@ some place when running the kernel inside QEMU, as QEMU somehow decides not to update its display buffer anymore under certain conditions. +# Halting the CPU and Examining Registers + IRC, freenode, #hurd, 2011-07-14: one ugly trick i use when printf isn't available is to halt the diff --git a/microkernel/mach/mig/gnu_mig/building.mdwn b/microkernel/mach/mig/gnu_mig/building.mdwn index 759c1a84..cd588341 100644 --- a/microkernel/mach/mig/gnu_mig/building.mdwn +++ b/microkernel/mach/mig/gnu_mig/building.mdwn @@ -1,3 +1,14 @@ +[[!meta copyright="Copyright © 2006, 2007, 2008, 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]]."]]"""]] + # Building the Mach Interface Generator from Source If you want to build the Mach Interface Generator yourself instead of just diff --git a/microkernel/mach/mig/gnu_mig/building/discussion.mdwn b/microkernel/mach/mig/gnu_mig/building/discussion.mdwn new file mode 100644 index 00000000..d7636158 --- /dev/null +++ b/microkernel/mach/mig/gnu_mig/building/discussion.mdwn @@ -0,0 +1,16 @@ +[[!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]]."]]"""]] + +# Non-cross-compiling + +[[!tag open_issue_mig]] + +[[samuelthibault]] mentioned that I should make clear what compiler options, etc. are only needed if compiling on a 64 bit computer. However, I don't know if the --host=i686... option is needed, here and when making gnumach, in case there may be some other default on 32 bit computers? --[[sudoman]] + diff --git a/microkernel/mach/mig/gnu_mig/discussion.mdwn b/microkernel/mach/mig/gnu_mig/discussion.mdwn deleted file mode 100644 index e5a4dea3..00000000 --- a/microkernel/mach/mig/gnu_mig/discussion.mdwn +++ /dev/null @@ -1,6 +0,0 @@ -# Builing MIG - -## Non-cross-compiling - -[[samuelthibault]] mentioned that I should make clear what compiler options, etc. are only needed if compiling on a 64 bit computer. However, I don't know if the --host=i686... option is needed, here and when making gnumach, in case there may be some other default on 32 bit computers? --[[sudoman]] - diff --git a/open_issues/e2fsck_i_file_acl_hi.mdwn b/open_issues/e2fsck_i_file_acl_hi.mdwn index f055babe..d03b733c 100644 --- a/open_issues/e2fsck_i_file_acl_hi.mdwn +++ b/open_issues/e2fsck_i_file_acl_hi.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!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 @@ -34,4 +34,5 @@ IRC, unknown channel, unknown date. k 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 +This is due to an erroneous read/write from e2fsck, see +. diff --git a/open_issues/libpthread_dlopen.mdwn b/open_issues/libpthread_dlopen.mdwn index 0cd761f2..0d3628ec 100644 --- a/open_issues/libpthread_dlopen.mdwn +++ b/open_issues/libpthread_dlopen.mdwn @@ -15,7 +15,7 @@ IRC, OFTC, #debian-hurd, 2011-07-21. there's one known issue with pthreads you can't dlopen() it -[ if the main application is not already linked against it ] +... if the main application is not already linked against it. which also means you can't dlopen() a module which depends on it if the main application hasn't used -lpthread already @@ -43,12 +43,12 @@ The fix thus being: link the main application with -lpthread. The same symptom appears in an odd case, for instance: -buildd@hurd:~$ ldd /usr/bin/openjade - libthreads.so.0.3 => /lib/libthreads.so.0.3 (0x0103d000) - libosp.so.5 => /usr/lib/libosp.so.5 (0x01044000) - libpthread.so.0.3 => /lib/libpthread.so.0.3 (0x01221000) - libnsl.so.1 => /lib/i386-gnu/libnsl.so.1 (0x01232000) -... + buildd@hurd:~$ ldd /usr/bin/openjade + libthreads.so.0.3 => /lib/libthreads.so.0.3 (0x0103d000) + libosp.so.5 => /usr/lib/libosp.so.5 (0x01044000) + libpthread.so.0.3 => /lib/libpthread.so.0.3 (0x01221000) + libnsl.so.1 => /lib/i386-gnu/libnsl.so.1 (0x01232000) + [...] openjade links against *both* libthreads and libpthread. The result is that libc early-initializes libthreads only, and thus libpthread is not early-initialized, diff --git a/open_issues/perl.mdwn b/open_issues/perl.mdwn index c7428cb5..45680328 100644 --- a/open_issues/perl.mdwn +++ b/open_issues/perl.mdwn @@ -10,16 +10,13 @@ License|/fdl]]."]]"""]] [[!meta title="Foster Perl programming"]] -A dependency loop in Debian GNU/Hurd currently leads to +[[!template id=note text="""**2011-08**. A dependency loop in Debian GNU/Hurd +currently leads to: *Could not perform immediate configuration on 'perl'*. +Easy workaround: -`Could not perform immediate configuration on 'perl'` - -Simply use - -`apt-get install perl perl-base -o APT::Immediate-Configure=false` - -to break the loop. + # apt-get install perl perl-base -o APT::Immediate-Configure=false +"""]] Resolve issues uncovered by Perl's test suite, and enable Hurd-specific diff --git a/open_issues/runit.mdwn b/open_issues/runit.mdwn index 6b336ef7..659b81ea 100644 --- a/open_issues/runit.mdwn +++ b/open_issues/runit.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!tag open_issue_porting]] @@ -26,36 +27,24 @@ Originally answered by Samuel Thibault: Usual issue with rpctrace: it does not support fork(). -I've checked a backtrace in gdb, got this: - - 0x0105af6c in mach_msg_trap () - at /build/eglibc-jWVnRE/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 - -1 0x0105b769 in __mach_msg (msg=0x1024af8, option=258, send_size=0, rcv_size=40, rcv_name=140, - timeout=1000020, notify=0) at msg.c:110 - -2 0x01062251 in _hurd_select (nfds=2, pollfds=0x1024dc0, readfds=0x0, writefds=0x0, exceptfds=0x0, - timeout=0x1024bbc, sigmask=0x0) at hurdselect.c:324 - -3 0x0114427b in __poll (fds=0x1024dc0, nfds=2, timeout=1000020) at ../sysdeps/mach/hurd/poll.c:48 - -4 0x0804b770 in iopause (x=0x1024dc0, len=2, deadline=0x1024dd8, stamp=0x1024de8) at iopause.c:29 - -5 0x08048efc in main (argc=2, argv=0x1024e94) at runsv.c:543 - - -and main() shows up as: - - sig_unblock(sig_term); - - sig_unblock(sig_child); - - -> iopause(x, 2 +haslog, &deadline, &now); - - sig_block(sig_term); - - sig_block(sig_child); - + I've checked a backtrace in gdb, got this: + + 0x0105af6c in mach_msg_trap () + at /build/eglibc-jWVnRE/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + 1 0x0105b769 in __mach_msg (msg=0x1024af8, option=258, send_size=0, rcv_size=40, rcv_name=140, + timeout=1000020, notify=0) at msg.c:110 + 2 0x01062251 in _hurd_select (nfds=2, pollfds=0x1024dc0, readfds=0x0, writefds=0x0, exceptfds=0x0, + timeout=0x1024bbc, sigmask=0x0) at hurdselect.c:324 + 3 0x0114427b in __poll (fds=0x1024dc0, nfds=2, timeout=1000020) at ../sysdeps/mach/hurd/poll.c:48 + 4 0x0804b770 in iopause (x=0x1024dc0, len=2, deadline=0x1024dd8, stamp=0x1024de8) at iopause.c:29 + 5 0x08048efc in main (argc=2, argv=0x1024e94) at runsv.c:543 + + and main() shows up as: + + sig_unblock(sig_term); + sig_unblock(sig_child); + -> iopause(x, 2 +haslog, &deadline, &now); + sig_block(sig_term); + sig_block(sig_child); So it simply looks like the known "signals don't interrupt select" bug. - diff --git a/open_issues/sync_but_still_unclean_filesystem.mdwn b/open_issues/sync_but_still_unclean_filesystem.mdwn index 8a0b1d49..c8a37169 100644 --- a/open_issues/sync_but_still_unclean_filesystem.mdwn +++ b/open_issues/sync_but_still_unclean_filesystem.mdwn @@ -33,6 +33,5 @@ Of course, [[hurd/translator/ext2fs]] is meant to be doing this to-disk synchronization internally upon translator shutdown, but evidently it doesn't in all cases. - Apparently diskfs simply does not set filesystem as readonly: - - http://lists.gnu.org/archive/html/bug-hurd/2011-08/msg00024.html +Apparently diskfs simply does not set filesystems as read-only: +. diff --git a/open_issues/virtualbox.mdwn b/open_issues/virtualbox.mdwn index 246313ff..9440284f 100644 --- a/open_issues/virtualbox.mdwn +++ b/open_issues/virtualbox.mdwn @@ -8,15 +8,16 @@ 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="xattr: extended attributes"]] - [[!tag open_issue_gnumach]] Running GNU Mach in VirtualBox crashes during initialization. IRC, freenode, #hurd, 2011-08-15 - HowTo Reproduce: 1) Use `reboot` to reboot the system. 2) Once you see the Grub menu, turn off the debian hurd box. 3) Let the box boot normally, and wait for the error/crash/reboot. 4) The error/crash will happen twice and it's reboot automatically. The 3rd boot will success. + HowTo Reproduce: 1) Use `reboot` to reboot the system. 2) Once + you see the Grub menu, turn off the debian hurd box. 3) Let the box boot + normally, and wait for the error/crash/reboot. 4) The error/crash will + happen twice and it's reboot automatically. The 3rd boot will success. root@dhurd:/boot# addr2line -f -e gnumach-1.3.99-486-dbg-copy 0x106c93 0x1556a5 0x152c54 copyoutmsg @@ -28,8 +29,8 @@ IRC, freenode, #hurd, 2011-08-15 i386/i386/locore.S:1289 is - movl $USER_DS,%eax /* use user data segment for accesses */ -=> mov %ax,%es + movl $USER_DS,%eax /* use user data segment for accesses */ + => mov %ax,%es State is @@ -66,14 +67,14 @@ IRC, freenode, #hurd, 2011-08-15 i386/i386/locore.S:527 is: -_return_from_kernel: -_kret_popl_gs: - popl %gs /* restore segment registers */ -_kret_popl_fs: - popl %fs -_kret_popl_es: -=> popl %es -_kret_popl_ds: + _return_from_kernel: + _kret_popl_gs: + popl %gs /* restore segment registers */ + _kret_popl_fs: + popl %fs + _kret_popl_es: + => popl %es + _kret_popl_ds: cs: 0x8 ds: 0x10 @@ -93,5 +94,6 @@ _kret_popl_ds: efl: 0x10216 looks again like a $USER_DS issue - what's interesting is that that one means that $USER_DS did load in %es fine at least once + what's interesting is that that one means that $USER_DS did load in + %es fine at least once and it's the reload that fails diff --git a/source_repositories.mdwn b/source_repositories.mdwn index df0242f0..5ac90b5e 100644 --- a/source_repositories.mdwn +++ b/source_repositories.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009, 2010 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2009, 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 @@ -22,14 +22,17 @@ This page is meant to give some guidelines. Please use good sense or ask on * hurd.git -- Hurd meta package; no real content yet * [[hurd/glibc.git|glibc]] -- [[/glibc]] maintenance - * hurd/gnumach.git -- [[GNU Mach|microkernel/mach/gnumach]] ([[building|microkernel/mach/gnumach/building]]) - * hurd/hurd.git -- [[/Hurd]] ([[building|hurd/building]]) + * hurd/gnumach.git -- [[GNU Mach|microkernel/mach/gnumach]] + ([[microkernel/mach/gnumach/building]]) + * hurd/hurd.git -- [[/Hurd]] ([[hurd/building]]) * [[hurd/incubator.git|incubator]] -- the great next stuff * hurd/libpthread.git -- [[POSIX threading library|libpthread]] - * hurd/mig.git -- [[microkernel/mach/MIG]] ([[building|microkernel/mach/mig/gnu_mig/building]]) + * hurd/mig.git -- [[microkernel/mach/MIG]] + ([[microkernel/mach/mig/gnu_mig/building]]) * hurd/procfs.git -- [[hurd/translator/procfs]] - * hurd/unionfs.git -- -- [[hurd/translator/unionfs]] - * hurd/viengoos.git -- [[microkernel/Viengoos]] ([[building|microkernel/viengoos/building]]) + * hurd/unionfs.git -- [[hurd/translator/unionfs]] + * hurd/viengoos.git -- [[microkernel/Viengoos]] + ([[microkernel/viengoos/building]]) * hurd/web.git -- [[contributing/Web_pages]] -- cgit v1.3.1 From 0149900126f7cc33c8a347f73a3c2148b8f2fbb8 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawmOlZj6Ku6rQ8E1D1Wl2ExOtSuLcJNVfyY" Date: Tue, 30 Aug 2011 18:25:01 +0200 Subject: Added stuff on GNU build system (and mentioned SA_NOCLDWAIT) --- hurd/porting/guidelines.mdwn | 28 +++++++++++++++++++++++++++- 1 file changed, 27 insertions(+), 1 deletion(-) (limited to 'hurd') diff --git a/hurd/porting/guidelines.mdwn b/hurd/porting/guidelines.mdwn index c5dd4891..529a6130 100644 --- a/hurd/porting/guidelines.mdwn +++ b/hurd/porting/guidelines.mdwn @@ -22,8 +22,30 @@ There is a separate page about [[System_API_Limitations]]. You may ask on the [[mailing lists/bug-hurd]] mailing list for details or questions about fixing bugs. +## GNU build system -## Fixing configure.ac/in +For a good overview of the components in the GNU build system, see + and +. + +The GNU build system distinguishes between 'build', 'host' and 'target' machines. +The 'build' machine is where compilers are run, the 'host' machine where the package +being built will run, and for cross compiling the 'target' machine, on which the compiler +built will generate code for. + +When using GNU autotools to configure a package config.guess and config.sub from autotools-dev +are used to find out the build machine identity: CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM. +For GNU/Hurd config.guess gives 'i686-unknown-gnu0.3'. Sometimes a quadruple is used +adding KERNEL, e.g. for Linux on an amd64: 'x86_64-unknown-linux-gnu'. config.sub is used to +canonicalize on these triplets, e.g. config.sub i686-gnu gives 'i686-pc-gnu'. + +On Debian systems the build Makefile is debian/rules and some Debian packages will set $host to +'i486-pc-gnu'. This is accomplished with the 'dpkg-architecture -qDEB_HOST_GNU_TYPE' construct +forwarded to configure in debian/rules, e.g. configure --host=$DEB_HOST_GNU_TYPE. +Another way to set $build, $host etc is via the Debian dh_auto_configure script from the debhelper +package which uses the Perl code autoconf.pm to find out these variables. + +## Fixing configure.{ac,in} The GNU/Hurd (and GNU/kFreeBSD) toolchain is extremely close to the GNU/Linux toolchain. configure.ac thus very often just needs to be fixed by using the same cases as Linux, that is, turn @@ -230,6 +252,10 @@ then be found. Not implemented, packages may be fixed for working around this: use void sighandler(int num) prototype and sa_handler field. +## `SA_NOCLDWAIT` + +Not implemented yet. + ## `SOL_IP` Not implemented yet. -- cgit v1.3.1 From 5eb2614baa5a6332a39674b4e80b3fedb09fcbc8 Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Wed, 31 Aug 2011 02:45:53 +0200 Subject: mention that SA_SIGINFO will be fixed in debian eglibc 2.13-19 --- hurd/porting/guidelines.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'hurd') diff --git a/hurd/porting/guidelines.mdwn b/hurd/porting/guidelines.mdwn index c5dd4891..c6ed62ed 100644 --- a/hurd/porting/guidelines.mdwn +++ b/hurd/porting/guidelines.mdwn @@ -228,7 +228,7 @@ then be found. ## `SA_SIGINFO` -Not implemented, packages may be fixed for working around this: use void sighandler(int num) prototype and sa_handler field. +Implemented by Jeremie Koenig, pending upload in Debian eglibc 2.13-19. ## `SOL_IP` -- cgit v1.3.1 From 75461902658117454c94d0f4847f73af1d4f97a0 Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Wed, 31 Aug 2011 02:50:57 +0200 Subject: explain that quadruples are actually triples --- hurd/porting/guidelines.mdwn | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'hurd') diff --git a/hurd/porting/guidelines.mdwn b/hurd/porting/guidelines.mdwn index e3da1e42..efc8982a 100644 --- a/hurd/porting/guidelines.mdwn +++ b/hurd/porting/guidelines.mdwn @@ -36,7 +36,9 @@ built will generate code for. When using GNU autotools to configure a package config.guess and config.sub from autotools-dev are used to find out the build machine identity: CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM. For GNU/Hurd config.guess gives 'i686-unknown-gnu0.3'. Sometimes a quadruple is used -adding KERNEL, e.g. for Linux on an amd64: 'x86_64-unknown-linux-gnu'. config.sub is used to +adding KERNEL, e.g. for Linux on an amd64: 'x86_64-unknown-linux-gnu'. This +is however actually a triple, it just happens that the operating system part +unfortunately contains a '-'. config.sub is used to canonicalize on these triplets, e.g. config.sub i686-gnu gives 'i686-pc-gnu'. On Debian systems the build Makefile is debian/rules and some Debian packages will set $host to -- cgit v1.3.1 From 3e7472b3d54853389cd8a17475901fbef976ef18 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 1 Sep 2011 09:27:33 +0200 Subject: IRC. --- hurd/subhurd/discussion.mdwn | 69 ++++ hurd/translator/discussion.mdwn | 25 ++ hurd/translator/procfs/jkoenig/discussion.mdwn | 23 ++ microkernel/discussion.mdwn | 24 ++ microkernel/mach/memory_object/discussion.mdwn | 24 ++ news/2011-q2-ps.mdwn | 33 ++ .../active_vs_passive_symlink_translator.mdwn | 44 +++ open_issues/clock_gettime.mdwn | 28 +- open_issues/code_analysis.mdwn | 7 + open_issues/glibc_init_first.mdwn | 78 ++++ open_issues/gnumach_memory_management.mdwn | 397 +++++++++++++++++++++ open_issues/hurd_101.mdwn | 38 ++ open_issues/libpthread_dlopen.mdwn | 30 +- open_issues/mach_tasks_memory_usage.mdwn | 49 ++- open_issues/mmap_crash_etc.mdwn | 95 +++++ open_issues/multiprocessing.mdwn | 37 +- open_issues/packaging_libpthread.mdwn | 5 +- open_issues/performance.mdwn | 4 + open_issues/performance/degradation.mdwn | 28 ++ .../performance/io_system/binutils_ld_64ksec.mdwn | 15 + .../performance/microkernel_multi-server.mdwn | 47 +++ open_issues/proc_server_proc_exception_raise.mdwn | 37 ++ open_issues/resource_management_problems.mdwn | 15 + .../io_accounting.mdwn | 49 +++ open_issues/sa_siginfo_sa_sigaction.mdwn | 49 ++- open_issues/sbcl.mdwn | 31 ++ open_issues/sendmsg_scm_creds.mdwn | 4 + open_issues/syslog.mdwn | 44 ++- open_issues/tty_activitiy_vs_disk_io.mdwn | 81 +++++ open_issues/user-space_device_drivers.mdwn | 36 ++ open_issues/wine.mdwn | 50 ++- open_issues/wine/rg6dx09G.patch | 116 ++++++ 32 files changed, 1598 insertions(+), 14 deletions(-) create mode 100644 hurd/subhurd/discussion.mdwn create mode 100644 hurd/translator/discussion.mdwn create mode 100644 microkernel/discussion.mdwn create mode 100644 microkernel/mach/memory_object/discussion.mdwn create mode 100644 open_issues/active_vs_passive_symlink_translator.mdwn create mode 100644 open_issues/glibc_init_first.mdwn create mode 100644 open_issues/hurd_101.mdwn create mode 100644 open_issues/mmap_crash_etc.mdwn create mode 100644 open_issues/performance/degradation.mdwn create mode 100644 open_issues/performance/microkernel_multi-server.mdwn create mode 100644 open_issues/proc_server_proc_exception_raise.mdwn create mode 100644 open_issues/resource_management_problems/io_accounting.mdwn create mode 100644 open_issues/sbcl.mdwn create mode 100644 open_issues/tty_activitiy_vs_disk_io.mdwn create mode 100644 open_issues/wine/rg6dx09G.patch (limited to 'hurd') diff --git a/hurd/subhurd/discussion.mdwn b/hurd/subhurd/discussion.mdwn new file mode 100644 index 00000000..3449edcd --- /dev/null +++ b/hurd/subhurd/discussion.mdwn @@ -0,0 +1,69 @@ +[[!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-08-10 + + < braunr> youpi: aren't sub-hurds actually called "neighbor hurds" ? + < youpi> no idea + < braunr> i also don't understand the recursive property + < youpi> a user can run a subhurd + < neal> braunr: What don't you understand? + < youpi> a user in a subhurd can run a subhurd + < youpi> etc + < braunr> i'm not sure it's really recursive + < neal> youpi: At some point it was observed that you don't strictly + require any resources from the "parent" Hurd. + < neal> youpi: i.e., you could have two Hurds running "directly" on Mach + < youpi> sure + < neal> youpi: Hence neighbor rather than sub + < youpi> but you need to be root for that + < youpi> or else your subhurd can't do much + < neal> you need to have been authorized to use the required resouces + < youpi> which is about the same :) + < neal> depends how they are delegated + < youpi> that's still asking root for something + < neal> if you say so + < youpi> which is most probably not the default + < braunr> well, either you depend on the parent to do things on your + behalf, or you directly have some privileged ports + < braunr> i'd agree with youpi that it's pretty much having root access at + some point + < youpi> and usually you don't have privileged ports by default :) + < braunr> but we don't need to restrict the presentation to user only sub + hurds + < braunr> people don't mind switching to root on their desktops + < braunr> which is one of the reasons they ask "what does the hurd really + bring me today ?" + < braunr> but being able to run truely separate hurds or recursive hurds is + something nice most OSes can't do easily + < youpi> switching to root becomes a *pain* when you have to do it 1 every + two commands + < braunr> yes sure, but some people might just say you're clumsy :x + < neal> The question is: can I start a sub-hurd from within another hurd + that survives the parent's hurd exiting? The answer is yes. The reason + is that the sub-hurd can be constructed in such a way that it does not + rely on the parent. In this case, the parent does not necessarily + subjugate the sub-hurd. Hence the name. + < braunr> but that's out of the scope of the discussion + < antrik> using the traditional, root only mechanism, neighbour-hurd is + indeed a more appropriate term. apart from the initial terminal being + proxied to the parent system by the boot program, they are really equal + < antrik> with zhengda's work on non-root subhurds, you rely on various + proxies in the parent system to access privileged resources; so subhurd + is indeed a more appropriate term in this case + < antrik> (not only non-root subhurds in fact... when using any of the + proxies, such as the network multiplexer -- even if still running as + root...) + < youpi> antrik: you could still give a com0 port as terminal + < antrik> I don't think that's actually supported in the boot + program... but it doesn't really matter, as you don't really need the + terminal anyways -- you can always log in through the network diff --git a/hurd/translator/discussion.mdwn b/hurd/translator/discussion.mdwn new file mode 100644 index 00000000..e038ba84 --- /dev/null +++ b/hurd/translator/discussion.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]]."]]"""]] + +[[!tag open_issue_documentation open_issue_hurd]] + +IRC, freenode, #hurd, 2011-08-25: + + < frhodes> how can I replace an existing running server with a new one + without rebooting? + < antrik> frhodes: depends. if other critical things depend on it, you + can't. there is no mechanism to serialize and pass on the open sessions + < antrik> in some situations, you can orphan the old translator while + starting a new one, so the previous clients will stay with the old one + while new one will get the new one + < antrik> obviously that only works for things that aren't exclusive by + nature + < antrik> in some cases, you might even be able simply to remove the old + translator... but obviously only for non-critical stuff :-) diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn index 64e3776e..01bbea42 100644 --- a/hurd/translator/procfs/jkoenig/discussion.mdwn +++ b/hurd/translator/procfs/jkoenig/discussion.mdwn @@ -184,3 +184,26 @@ IRC, freenode, #hurd, 2011-07-22 status is 644 though but status contains information which anyone can ask to the proc server anyway, I think. + + +# `/proc/mounts`, `/proc/$pid/mounts` + +IRC, freenode, #hurd, 2011-07-25 + + < pinotree> jkoenig: btw, what do you think about providing empty + /proc/mounts and /proc/$pid/mounts files? + < jkoenig> pinotree, I guess one would have to evaluate the consequences + wrt. existing use cases (in other words, "I have absolutely no clue + whatsoever about whether that would be desirable" :-) + < jkoenig> pinotree, the thing is, an error message like "/proc/mounts: No + such file or directory" is rather explicit, whereas errors which would be + caused by missing data in /proc/mounts would maybe be harder to track + < braunr> this seems reasonable though + < braunr> there already are many servers with e.g. grsecurity or chrooted + environments where mounts is empty + < pinotree> well, currently we also have an empty mtab + < braunr> pinotree: but what do you need that for ? + < braunr> pinotree: the init system ? + < pinotree> and the mnt C api already returns no entries (or it bails out, + i don't remember) + < pinotree> not a strict need diff --git a/microkernel/discussion.mdwn b/microkernel/discussion.mdwn new file mode 100644 index 00000000..a5a73e18 --- /dev/null +++ b/microkernel/discussion.mdwn @@ -0,0 +1,24 @@ +[[!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-07-26: + + < antrik> Tekk_`: regarding microkernels: the basic idea, and really the + *only* fundamental difference, is that they isolate things in separate + address spaces. everything else goes back to this. + < antrik> benefits from the isolation generally fall into two groups: more + robustness (main focus of Minix3), and more flexibility (main focus of + Hurd) + < antrik> while it might also encourage some other good design choices, + these are secondary effects: such choices can also be implemented in a + monolithic architecture -- and not necessarily harder. just less obvious + in some cases... diff --git a/microkernel/mach/memory_object/discussion.mdwn b/microkernel/mach/memory_object/discussion.mdwn new file mode 100644 index 00000000..a006429b --- /dev/null +++ b/microkernel/mach/memory_object/discussion.mdwn @@ -0,0 +1,24 @@ +[[!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_gnumach]] + +IRC, freenode, #hurd, 2011-08-05 + + < neal> braunr: For instance, memory objects are great as they allow you to + specify the mapping policy in user space. + < neal> braunr: But, the policy for determining the eviction order is + realized by Mach + < neal> braunr: And user-space has no control + < braunr> are you referring to the page cache lru approximation and stuff + like resource containers ? + < neal> I'm not sure what you mean by page cache lru appoximateion + < braunr> the kernel eviction policy :) + < neal> that's an implementation detail diff --git a/news/2011-q2-ps.mdwn b/news/2011-q2-ps.mdwn index cbf039b0..14578e83 100644 --- a/news/2011-q2-ps.mdwn +++ b/news/2011-q2-ps.mdwn @@ -95,4 +95,37 @@ slashdot and phoronix did some [performance tests of the Hurd][phorperf], [phorperf]: http://www.phoronix.com/scan.php?page=article&item=debian_gnu_hurd&num=1 +--- + +IRC, freenode, #hurd, 2011-08-24: + + < ArneBab> hurd related: I now think you were right, antrik: the hurd + rumors don’t belong into the news (tschwinge) + < antrik> ArneBab: you mean the postscriptum as a whole, or just the wild + rumours part?... + < ArneBab> the whole PS + < ArneBab> it should rather go into a blog post + < ArneBab> (in the wiki) + < antrik> hm... I don't think I agree + < ArneBab> why? + < antrik> apparently there is a number of people following the news now, + and apparently many of them misread some statements... it makes sense to + use the same channel for clarifying them I'd say + < ArneBab> hm, ok + < ArneBab> how would you select the part to include? + < antrik> roughly speaking, I'd include everything that actually relates to + the previous news that were misunderstood + < antrik> and drop all unrelated speculations that popped up + < antrik> BTW, it *might* be useful perhaps to actually update the original + news posting with the clarifications?... + < ArneBab> we can’t do that without breaking some peoples RSS feeds + < antrik> note that there is another aspect to consider: the fact that + several news sites picked it up is indeed genuine news by itself... + < ArneBab> that’s right, yes + < antrik> will it really break anything? from what I heard so far it just + means they will see the posting as new again, which would actually make + sense in this case... + < antrik> but I don't insist if you think it's too risky :-) + < antrik> just an idea + --> 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/clock_gettime.mdwn b/open_issues/clock_gettime.mdwn index bba0d171..c06edc9b 100644 --- a/open_issues/clock_gettime.mdwn +++ b/open_issues/clock_gettime.mdwn @@ -12,8 +12,30 @@ License|/fdl]]."]]"""]] [[!tag open_issue_glibc open_issue_gnumach]] -Missing clock_gettime(CLOCK_MONOTONIC) (e.g. for iceweasel) +Missing `clock_gettime(CLOCK_MONOTONIC)` (e.g. for iceweasel) -It could be a mere matter of extending the mappable clock: add it to mapped_time_value_t in gnumach, handle it in gnumach/kern/mach_clock.c, and make clock_gettime use it. +It could be a mere matter of extending the mappable clock: 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. +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 diff --git a/open_issues/code_analysis.mdwn b/open_issues/code_analysis.mdwn index ab90a6b6..552cd2c9 100644 --- a/open_issues/code_analysis.mdwn +++ b/open_issues/code_analysis.mdwn @@ -27,6 +27,13 @@ analysis|performance]], [[formal_verification]], as well as general * [[!wikipedia List_of_tools_for_static_code_analysis]] + * [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 * diff --git a/open_issues/glibc_init_first.mdwn b/open_issues/glibc_init_first.mdwn new file mode 100644 index 00000000..774b7828 --- /dev/null +++ b/open_issues/glibc_init_first.mdwn @@ -0,0 +1,78 @@ +[[!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_glibc]] + +IRC, freenode, #hurd, 2011-07-22 + + [additional init-first.c patch] + < tschwinge> civodul: The only thing I wonder about: Roland also once had + done similar changes, which I then found they didn'T work with GCC 4.1, + and backed them out in 08f53ee9d265ffdc7e0affd6acf346cceeb65559 and fixed + the issue differently in d8d27e633a7860b37fd2e3142822b640a066cc0f (and + e17cef66140d4c97710ea88bd8d12612799e1e0f). Have you reviewed this? + < tschwinge> That's in the Savannah glibc repository. + < tschwinge> And this has been in 2007, four years ago. I don't remember + all the details. + < tschwinge> And here is quite a good summary of this stuff, from + init-first.c: + < tschwinge> /* XXX This is all a crock and I am not happy with it. + < tschwinge> This poorly-named function is called by static-start.S, + < civodul> braunr: thanks; i must admit it took me a while to figure it out + ;-) + < tschwinge> which should not exist at all. */ + < tschwinge> civodul: I can imagine... :-/ + < civodul> tschwinge: re Roland's changes, that's weird; i plan to try to + reinstate his change and see if it works + < civodul> now, i won't test with GCC 4.1... + < tschwinge> Yeah... + < tschwinge> I'm happy if it works with 4.4 onwards. + < tschwinge> civodul: And it's safe (in GCC terms) to write to ``* ((void + **) __builtin_frame_address (0) + 1)'', and similar? + < tschwinge> Or should we be coding this few stuff in assembly? + < civodul> tschwinge: well, we should add a compile-time assertion for + __builtin_return_address (0) == *((void**)__builtin_frame_address (0) + + 1) + < civodul> (i think GCC can figure it out at compile-time) + < civodul> but on IA32 it should always be true + < civodul> what's the name of glibc's compile-time assert macro already? + < tschwinge> I wonder whether that might interfere with some of GCC's + optimizations? + < civodul> what? + < tschwinge> Well, it seems unclean for me to be modifying a function's + return address from within C code. + < tschwinge> civodul: I added a verify.h in the t/verify.h branch. But + people didn't really like it too much. They rather wanted to directly + inline the array[(cond)?1:-1] code. + < civodul> ok + < civodul> i remember a debate about Gnulib's verify.h + < civodul> i thought something comparable had landed eventually + < tschwinge> civodul: Oh, maybe I missed it. + < tschwinge> civodul: In init-first.c:init, what about the usage of + data[-1] in the else path (not using cthreads) -- is that good as-is? + < civodul> tschwinge: oooh, it probably needs to fixed too + < civodul> but i haven't reached that point yet ;-) + * civodul tries to cross-bootstrap GNU from scratch + < tschwinge> civodul: I'd be happy to learn what was wrong with Roland's + original idea of fixing this. Or perhaps this was a GCC 4.1 bug? Or + perhaps GCC was inlining to much, and then got confused with frames and + return addresses? + < civodul> tschwinge: Roland's change looks good to me, so it could have + been a GCC bug + < civodul> tschwinge: OK to commit the patch to t/init-first.c (with both + data[-1] replaced)? + < tschwinge> civodul: OK, if you are confident that it works with GCC 4.4 + onwards. If yes, please add your changelog snippet to .topmsg, and also + add a not that Roland's original code may in fact have been fine, and we + may have hit a compiler bug. + < civodul> tschwinge: OK, will do + < civodul> tschwinge: though regarding Roland's change, i'd prefer to + actually test and see + < tschwinge> civodul: Thanks! diff --git a/open_issues/gnumach_memory_management.mdwn b/open_issues/gnumach_memory_management.mdwn index 448aafcc..a728fc9d 100644 --- a/open_issues/gnumach_memory_management.mdwn +++ b/open_issues/gnumach_memory_management.mdwn @@ -923,3 +923,400 @@ There is a [[!FF_project 266]][[!tag bounty]] on this task. 20 years ago but it's a source of deadlock Indeed. I'll won't use kmem_alloc_pageable. + + +# IRC, freenode, #hurd, 2011-08-09 + + < braunr> mcsim: what's the "bug related to MEM_CF_VERIFY" you refer to in + one of your commits ? + < braunr> mcsim: don't use spin_lock_t as a member of another structure + < mcsim> braunr: I confused with types in *_verify functions, so they + didn't work. Than I fixed it in the commit you mentioned. + < braunr> in gnumach, most types are actually structure pointers + < braunr> use simple_lock_data_t + < braunr> mcsim: ok + < mcsim> > use simple_lock_data_t + < mcsim> braunr: ok + < braunr> mcsim: don't make too many changes to the code base, and if + you're unsure, don't hesitate to ask + < braunr> also, i really insist you rename the allocator, as done in x15 + for example + (http://git.sceen.net/rbraun/x15mach.git/?a=blob;f=vm/kmem.c), instead of + a name based on mine :/ + < mcsim> braunr: Ok. It was just work name. When I finish I'll rename the + allocator. + < braunr> other than that, it's nice to see progress + < braunr> although again, it would be better with some reports along + < braunr> i won't be present at the meeting tomorrow unfortunately, but you + should use those to report the status of your work + < mcsim> braunr: You've said that I have to tweak gc process. Did you mean + to call mem_gc() when physical memory ends instead of calling it every x + seconds? Or something else? + < braunr> there are multiple topics, alhtough only one that really matters + < braunr> study how zone_gc was called + < braunr> reclaiming memory should happen when there is pressure on the VM + subsystem + < braunr> but it shouldn't happen too ofte, otherwise there is trashing + < braunr> and your caches become mostly useless + < braunr> the original slab allocator uses a 15-second period after a + reclaim during which reclaiming has no effect + < braunr> this allows having a somehow stable working set for this duration + < braunr> the linux slab allocator uses 5 seconds, but has a more + complicated reclaiming mechanism + < braunr> it releases memory gradually, and from reclaimable caches only + (dentry for example) + < braunr> for x15 i intend to implement the original 15 second interval and + then perform full reclaims + < mcsim> In zalloc mem_gc is called by vm_pageout_scan, but not often than + once a second. + < mcsim> In balloc I've changed interval to once in 15 seconds. + < braunr> don't use the code as it is + < braunr> the version you've based your work on was meant for userspace + < braunr> where there isn't memory pressure + < braunr> so a timer is used to trigger reclaims at regular intervals + < braunr> it's different in a kernel + < braunr> mcsim: where did you see vm_pageout_scan call the zone gc once a + second ? + < mcsim> vm_pageout_scan calls consider_zone_gc and consider_zone_gc checks + if second is passed. + < braunr> where ? + < mcsim> Than zone_gc can be called. + < braunr> ah ok, it's in zaclloc.c then + < braunr> zalloc.c + < braunr> yes this function is fine + < mcsim> so old gc didn't consider vm pressure. Or I missed something. + < braunr> it did + < mcsim> how? + < braunr> well, it's called by the pageout daemon + < braunr> under memory pressure + < braunr> so it's fine + < mcsim> so if mem_gc is called by pageout daemon is it fine? + < braunr> it must be changed to do something similar to what + consider_zone_gc does + < mcsim> It does. mem_gc does the same work as consider_zone_gc and + zone_gc. + < braunr> good + < mcsim> so gc process is fine? + < braunr> should be + < braunr> i see mem.c only includes mem.h, which then includes other + headers + < braunr> don't do that + < braunr> always include all the headers you need where you need them + < braunr> if you need avltree.h in both mem.c and mem.h, include it in both + files + < braunr> and by the way, i recommend you use the red black tree instead of + the avl type + < braunr> (it's the same interface so it shouldn't take long) + < mcsim> As to report. If you won't be present at the meeting, I can tell + you what I have to do now. + < braunr> sure + < braunr> in addition, use GPLv2 as the license, teh BSD one is meant for + the userspace version only + < braunr> GPLv2+ actually + < braunr> hm you don't need list.c + < braunr> it would only add dead code + < braunr> "Zone for dynamical allocator", don't mix terms + < braunr> this comment refers to a vm_map, so call it a map + < mcsim> 1. Change constructor for kentry_alloc_cache. + < mcsim> 2. Make measurements. + < mcsim> + + < mcsim> 3. Use simple_lock_data_t + < mcsim> 4. Replace license + < braunr> kentry_alloc_cache <= what is that ? + < braunr> cache for kernel map entries in vm_map ? + < braunr> the comment for mem_cpu_pool_get doesn't apply in gnumach, as + there is no kernel preemption + < braunr> "Don't attempt mem GC more frequently than hz/MEM_GC_INTERVAL + times a second. + < braunr> " + < mcsim> sorry. I meant vm_map_kentry_cache + < braunr> hm nothing actually about this comment + < braunr> mcsim: ok + < braunr> yes kernel map entries need special handling + < braunr> i don't know how it's done in gnumach though + < braunr> static preallocation ? + < mcsim> yes + < braunr> that's ugly :p + < mcsim> but it uses dynamic allocation further even for vm_map kernel + entries + < braunr> although such bootstrapping issues are generally difficult to + solve elegantly + < braunr> ah + < mcsim> now I use only static allocation, but I'll add dynamic allocation + too + < braunr> when you have time, mind the coding style (convert everything to + gnumach style, which mostly implies using tabs instead of 4-spaces + indentation) + < braunr> when you'll work on dynamic allocation for the kernel map + entries, you may want to review how it's done in x15 + < braunr> the mem_source type was originally intended for that purpose, but + has slightly changed once the allocator was adapted to work in my kernel + < mcsim> ok + < braunr> vm_map_kentry_zone is the only zone created with ZONE_FIXED + < braunr> and it is zcram()'ed immediately after + < braunr> so you can consider it a statically allocated zone + < braunr> in x15 i use another strategy: there is a special kernel submap + named kentry_map which contains only one map entry (statically allocated) + < braunr> this map is the backend (mem_source) for the kentry_cache + < braunr> the kentry_cache is created with a special flag that tells it + memory can't be reclaimed + < braunr> when the cache needs to grow, the single map entry is extended to + cover the allocated memory + < braunr> it's similar to the way pmap_growkernel() works for kernel page + table pages + < braunr> (and is actually based on that idea) + < braunr> it's a compromise between full static and dynamic allocation + types + < braunr> the advantage is that the allocator code can be used (so there is + no need for a special allocator like in netbsd) + < braunr> the drawback is that some resources can never be returned to + their source (and under peaks, the amount of unfreeable resources could + become large, but this is unexpected) + < braunr> mcsim: for now you shouldn't waste your time with this + < braunr> i see the number of kernel map entries is fixed at 256 + < braunr> and i've never seen the kernel use more than around 30 entries + < mcsim> Do you think that I have to left this problem to the end? + < braunr> yes + + +# IRC, freenode, #hurd, 2011-08-11 + + < mcsim> braunr: Hello. Can you give me an advice how can I make + measurements better? + < braunr> mcsim: what kind of measurements + < mcsim> braunr: How much is your allocator better than zalloc. + < braunr> slightly :p + < braunr> that's why i never took the time to put it in gnumach + < mcsim> braunr: Just I thought that there are some rules or + recommendations of such measurements. Or I can do them any way I want? + < braunr> mcsim: i don't know + < braunr> mcsim: benchmarking is an art of its own, and i don't even know + how to use the bits of profiling code available in gnumach (if it still + works) + < antrik> mcsim: hm... are you saying you already have a running system + with slab allocator?... :-) + < braunr> mcsim: the main advantage i can see is the removal of many + arbitrary hard limits + < mcsim> antrik: yes + < antrik> \o/ + < antrik> nice work! + < braunr> :) + < braunr> the cpu layer should also help a bit, but it's hard to measure + < braunr> i guess it could be seen on the ipc path for very small buffers + < mcsim> antrik: Thanks. But I still have to 1. Change constructor for + kentry_alloc_cache. and 2. Make measurements. + < braunr> and polish the whole thing :p + < antrik> mcsim: I'm not sure this can be measured... the performance + differente in any real live usage is probably just a few percent at most + -- it's hard to construct a benchmark giving enough precision so it's not + drowned in noise... + < antrik> perhaps it conserves some memory -- but that too would be hard to + measure I fear + < braunr> yes + < braunr> there *should* be better allocation times, less fragmentation, + better accounting ... :) + < braunr> and no arbitrary limits ! + < antrik> :-) + < braunr> oh, and the self debugging features can be nice too + < mcsim> But I need to prove that my work wasn't useless + < braunr> well it wasn't, but that's hard to measure + < braunr> it's easy to prove though, since there are additional features + that weren't present in the zone allocator + < mcsim> Ok. If there are some profiling features in gnumach can you give + me a link with their description? + < braunr> mcsim: sorry, no + < braunr> mcsim: you could still write the basic loop test, which counts + the number of allocations performed in a fixed time interval + < braunr> but as it doesn't match many real life patterns, it won't be very + useful + < braunr> and i'm afraid that if you consider real life patterns, you'll + see how negligeable the improvement can be compared to other operations + such as memory copies or I/O (ouch) + < mcsim> Do network drivers use this allocator? + < mcsim> ok. I'll scrape up some test and than I'll report results. + + +# IRC, freenode, #hurd, 2011-08-26 + + < mcsim> hello. Are there any analogs of copy_to_user and copy_from_user in + linux for gnumach? + < mcsim> Or how can I determine memory map if I know address? I need this + for vm_map_copyin + < guillem> mcsim: vm_map_lookup_entry? + < mcsim> guillem: but I need to transmit map to this function and it will + return an entry which contains specified address. + < mcsim> And I don't know what map have I transmit. + < mcsim> I need to transfer static array from kernel to user. What map + contains static data? + < antrik> mcsim: Mach doesn't have copy_{from,to}_user -- instead, large + chunks of data are transferred as out-of-line data in IPC messages + (i.e. using VM magic) + < mcsim> antrik: can you give me an example? I just found using + vm_map_copyin in host_zone_info. + < antrik> no idea what vm_map_copyin is to be honest... + + +# IRC, freenode, #hurd, 2011-08-27 + + < braunr> mcsim: the primitives are named copyin/copyout, and they are used + for messages with inline data + < braunr> or copyinmsg/copyoutmsg + < braunr> vm_map_copyin/out should be used for chunks larger than a page + (or roughly a page) + < braunr> also, when writing to a task space, see which is better suited: + vm_map_copyout or vm_map_copy_overwrite + < mcsim> braunr: and what will be src_map for vm_map_copyin/out? + < braunr> the caller map + < braunr> which you can get with current_map() iirc + < mcsim> braunr: thank you + < braunr> be careful not to leak anything in the transferred buffers + < braunr> memset() to 0 if in doubt + < mcsim> braunr:ok + < braunr> antrik: vm_map_copyin() is roughly vm_read() + < antrik> braunr: what is it used for? + < braunr> antrik: 01:11 < antrik> mcsim: Mach doesn't have + copy_{from,to}_user -- instead, large chunks of data are transferred as + out-of-line data in IPC messages (i.e. using VM magic) + < braunr> antrik: that "VM magic" is partly implemented using vm_map_copy* + functions + < antrik> braunr: oh, you mean it doesn't actually copy data, but only page + table entries? if so, that's *not* really comparable to + copy_{from,to}_user()... + + +# IRC, freenode, #hurd, 2011-08-28 + + < braunr> antrik: the equivalent of copy_{from,to}_user are + copy{in,out}{,msg} + < braunr> antrik: but when the data size is about a page or more, it's + better not to copy, of course + < antrik> braunr: it's actually not clear at all that it's really better to + do VM magic than to copy... + + +# IRC, freenode, #hurd, 2011-08-29 + + < braunr> antrik: at least, that used to be the general idea, and with a + simpler VM i suspect it's still true + < braunr> mcsim: did you progress on your host_zone_info replacement ? + < braunr> mcsim: i think you should stick to what the original + implementation did + < braunr> which is making an inline copy if caller provided enough space, + using kmem_alloc_pageable otherwise + < braunr> specify ipc_kernel_map if using kmem_alloc_pageable + < mcsim> braunr: yes. And it works. But I use kmem_alloc, not pageable. Is + it worse? + < mcsim> braunr: host_zone_info replacement is pushed to savannah + repository. + < braunr> mcsim: i'll have a look + < mcsim> braunr: I've pushed one more commit just now, which has attitude + to host_zone_info. + < braunr> mem_alloc_early_init should be renamed mem_bootstrap + < mcsim> ok + < braunr> mcsim: i don't understand your call to kmem_free + < mcsim> braunr: It shouldn't be there? + < braunr> why should it be there ? + < braunr> you're freeing what the copy object references + < braunr> it's strange that it even works + < braunr> also, you shouldn't pass infop directly as the copy object + < braunr> i guess you get a warning for that + < braunr> do what the original code does: use an intermediate copy object + and a cast + < mcsim> ok + < braunr> another error (without consequence but still, you should mind it) + < braunr> simple_lock(&mem_cache_list_lock); + < braunr> [...] + < braunr> kr = kmem_alloc(ipc_kernel_map, &info, info_size); + < braunr> you can't hold simple locks while allocating memory + < braunr> read how the original implementation works around this + < mcsim> ok + < braunr> i guess host_zone_info assumes the zone list doesn't change much + while unlocked + < braunr> or that's it's rather unimportant since it's for debugging + < braunr> a strict snapshot isn't required + < braunr> list_for_each_entry(&mem_cache_list, cache, node) max_caches++; + < braunr> you should really use two separate lines for readability + < braunr> also, instead of counting each time, you could just maintain a + global counter + < braunr> mcsim: use strncpy instead of strcpy for the cache names + < braunr> not to avoid overflow but rather to clear the unused bytes at the + end of the buffer + < braunr> mcsim: about kmem_alloc vs kmem_alloc_pageable, it's a minor + issue + < braunr> you're handing off debugging data to a userspace application + < braunr> a rather dull reporting tool in most cases, which doesn't require + wired down memory + < braunr> so in order to better use available memory, pageable memory + should be used + < braunr> in the future i guess it could become a not-so-minor issue though + < mcsim> ok. I'll fix it + < braunr> mcsim: have you tried to run the kernel with MC_VERIFY always on + ? + < braunr> MEM_CF_VERIFY actually + < mcsim1> yes. + < braunr> oh + < braunr> nothing wrong + < braunr> ? + < mcsim1> it is always set + < braunr> ok + < braunr> ah, you set it in macros.h .. + < braunr> don't + < braunr> put it in mem.c if you want, or better, make it a compile-time + option + < braunr> macros.h is a tiny macro library, it shouldn't define such + unrelated options + < mcsim1> ok. + < braunr> mcsim1: did you try fault injection to make sure the checking + code actually works and how it behaves when an error occurs ? + < mcsim1> I think that when I finish I'll merge files cpu.h and macros.h + with mem.c + < braunr> yes that would simplify things + < mcsim1> Yes. When I confused with types mem_buf_fill worked wrong and + panic occurred. + < braunr> very good + < braunr> have you progressed concerning the measurements you wanted to do + ? + < mcsim1> not much. + < braunr> ok + < mcsim1> I think they will be ready in a few days. + < antrik> what measurements are these? + < mcsim1> braunr: What maximal size for static data and stack in kernel? + < braunr> what do you mean ? + < braunr> kernel stacks are one page if i'm right + < braunr> static data (rodata+data+bss) are limited by grub bugs only :) + < mcsim1> braunr: probably they are present, because when I created too big + array I couldn't boot kernel + < braunr> local variable or static ? + < mcsim1> static + < braunr> how large ? + < mcsim1> 4Mb + < braunr> hm + < braunr> it's not a grub bug then + < braunr> i was able to embed as much as 32 MiB in x15 while doing this + kind of tests + < braunr> I guess it's the gnu mach boot code which only preallocates one + page for the initial kernel mapping + < braunr> one PTP (page table page) maps 4 MiB + < braunr> (x15 does this completely dynamically, unlike mach or even + current BSDs) + < mcsim1> antrik: First I want to measure time of each cache + creation/allocation/deallocation and then compile kernel. + < braunr> cache creation is irrelevant + < braunr> because of the cpu pools in the new allocator, you should test at + least two different allocation patterns + < braunr> one with quick allocs/frees + < braunr> the other with large numbers of allocs then their matching frees + < braunr> (larger being at least 100) + < braunr> i'd say the cpu pool layer is the real advantage over the + previous zone allocator + < braunr> (from a performance perspective) + < mcsim1> But there is only one cpu + < braunr> it doesn't matter + < braunr> it's stil a very effective cache + < braunr> in addition to reducing contention + < braunr> compare mem_cpu_pool_pop() against mem_cache_alloc_from_slab() + < braunr> mcsim1: work is needed to polish the whole thing, but getting it + actually working is a nice achievement for someone new on the project + < braunr> i hope it helped you learn about memory allocation, virtual + memory, gnu mach and the hurd in general :) + < antrik> indeed :-) diff --git a/open_issues/hurd_101.mdwn b/open_issues/hurd_101.mdwn new file mode 100644 index 00000000..5c7031c9 --- /dev/null +++ b/open_issues/hurd_101.mdwn @@ -0,0 +1,38 @@ +[[!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]]."]]"""]] + +(See Wikipedia page for the meaning of [[!wikipedia "101_(term)"]].) + +Not the first time that something like this is proposed... + +IRC, freenode, #hurd, 2011-07-25 + + [failed GNU/Hurd project] + < antrik> gnu_srs1: I wouldn't say he was on track. just one of the many + many people who insist on picking a hard task; realizing that indeed it's + hard; and going into hiding + < antrik> we see that happen every couple of months + < cluck> maybe we need a "hurd 101" + < cluck> getting a teacher and setting up a regularly held "class" for hurd + noobs + < Tekk_> cluck: what would that include? + < cluck> explaining core concepts, giving out "homework" (small tasks), etc + < cluck> that way "the big guys" could focus on the hard stuff and have an + army of code monkeys at their disposal to write speced stuff + < cluck> (then again this idea would heavily depend on available "teachers" + and "students", which, going by gsoc numbers, may not be all that + helpful) + < Tekk_> cluck: gsoc isn't an accurate indicator + < Tekk_> cluck: I'm not allowed to participate in gsoc but I'd join :P + < antrik> cluck: we don't need code monkeys... we need hackers + < Tekk_`> antrik: code monkeys involve into hackers + < Tekk_`> under the right conditions + < cluck> antrik: jokes aside some sort of triage system/training ground for + newcomers could be helpful diff --git a/open_issues/libpthread_dlopen.mdwn b/open_issues/libpthread_dlopen.mdwn index 0d3628ec..fb665c67 100644 --- a/open_issues/libpthread_dlopen.mdwn +++ b/open_issues/libpthread_dlopen.mdwn @@ -40,8 +40,36 @@ IRC, OFTC, #debian-hurd, 2011-07-21. The fix thus being: link the main application with -lpthread. -The same symptom appears in an odd case, for instance: +IRC, freenode, #hurd, 2011-08-17 + + < youpi> i.e. openjade apparently dlopen()s modules which use pthreads, but + openjade itself is not liked against libpthread + < youpi> which means unexpectedly loading pthreads on the fly, which is + not implemented + < youpi> (and hard to implement of course) + < youpi> gnu_srs: so simply tell openjade people to link it with -lpthread + < gnu_srs> Shuoldn't missing linking with pthread create an error when + building openjade then? + < youpi> no + < youpi> because it's just a module which needs pthread + < youpi> and that module _is_ linked with -lpthread + < youpi> and dlopen() loads libpthreads too due to that + < youpi> but that's unexpected, for the libpthread initialization stuff + < youpi> (and too late to fix initlaization) + < gnu_srs> How come that other OSes build opensp w/o problems? + < youpi> because there are stubs in the libc + < gnu_srs> Sorry for the delay: What hinders stubs to be present also in + the Hurd libc parts too, to cope with this problem? + < youpi> doing it + < youpi> which is hard because you need libpthread bits inside the libc + < youpi> making it simpler would need building libpthread at the same time + as libc + +[[packaging_libpthread]] +--- + +The same symptom appears in an odd case, for instance: buildd@hurd:~$ ldd /usr/bin/openjade libthreads.so.0.3 => /lib/libthreads.so.0.3 (0x0103d000) diff --git a/open_issues/mach_tasks_memory_usage.mdwn b/open_issues/mach_tasks_memory_usage.mdwn index 88e3afb8..9abb7639 100644 --- a/open_issues/mach_tasks_memory_usage.mdwn +++ b/open_issues/mach_tasks_memory_usage.mdwn @@ -10,7 +10,7 @@ License|/fdl]]."]]"""]] [[!tag open_issue_documentation]] -IRC, #hurd, 2011-01-06. +IRC, freenode, #hurd, 2011-01-06 hm, odd... vmstat tells me that ~500 MiB of RAM are in use; but the sum of all RSS is <300 MiB... what's the rest? @@ -98,3 +98,50 @@ IRC, #hurd, 2011-01-06. braunr: yeah for bootstrapping issues, makes sense it may also depends on the pic/pie options used when building libraries + + +IRC, freenode, #hurd, 2011-07-24 + + < braunr> the panic is probably due to memory shortage + < braunr> so as antrik suggested, use more swap + < antrik> gg0: you could run "vmstat 1" in another terminal to watch memory + usage + < antrik> that way we will know for sure whether it's related + < braunr> antrik: it's trickier than that + < braunr> it depends if the zones used are pageable + < antrik> braunr: well, if it's a zone map exhaustion, then the swap size + won't change anything?... + < braunr> antrik: in this case no, but if the zone is pageable and the + pager (backing anonymous memory) refuses to create memory because it + estimates it's full (all swap space is reserved), it will fail to + < braunr> too + < braunr> but i don't think there are much pageable zones in the kernel + < antrik> yes, but in that case we can see the exhaustion in vmstat :-) + < braunr> many* + < braunr> i'm not sure + < braunr> reserved swap space doesn't mean it's used + < braunr> that's one of the major changes in freebsd 4 or 5 i was + mentioning + < antrik> if it's reserved, it wouldn't show up as "free", would it?... + < braunr> (btw, it's also what makes anonymous memory merging so hard) + < braunr> yes it would + < braunr> well, it could, i'm not sure + < braunr> anonymous memory is considered as a file + < braunr> one big file filled with zeroes, which is the swap partition + < braunr> when you allocate pageable anonymous memory, a part of this + "file" is reserved + < braunr> but i don't know if the reported number if the reserved + (allocated) space, or used (actually containing data) + < braunr> is* + < braunr> i also suspect wired allocations can fail because of a full swap + (because the kernel is unable to make free pages) + < braunr> in this case vmstat will show it + < antrik> what does it matter whether there is data there or not? if it's + reserved, it's not free. if it behaves differently, I'd consider that a + serious bug + < braunr> maybe the original developers intended to monitor its actual + usage + < braunr> antrik: i've just checked how the free count gets updated, and it + looks like it is on both seqnos_memory_object_data_initialize and + seqnos_memory_object_data_write + < braunr> antrik: so i guess reserved memory is accounted for diff --git a/open_issues/mmap_crash_etc.mdwn b/open_issues/mmap_crash_etc.mdwn new file mode 100644 index 00000000..4946a5a0 --- /dev/null +++ b/open_issues/mmap_crash_etc.mdwn @@ -0,0 +1,95 @@ +[[!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]]."]]"""]] + +Several issues here: + + * [[!tag open_issue_glibc open_issue_gnumach]] Even invalid `mmap` shoudn't + crash the process. + + * [[!tag open_issue_documentation]] The memory layout example should be + documented. + + * [[!tag open_issue_gnumach]] New `vm_map` allocation strategy may be + desirable; see also [[placement_of_virtual_memory_regions]]. + + * [[!tag open_issue_glibc]] *task X deallocating an invalid port Y, most + probably a bug*. + +IRC, freenode, #hurd, 2011-08-11 + + < zyg> oh, mmap sigsegvs, strange. + < braunr> hwo do you see that ? + < zyg> braunr: I'll try to paste a minimal case + < braunr> zyg: make sure you have a sane memory setup + < braunr> 512 RAM / 1G swap seems good + < braunr> have more swap than RAM + < zyg> I have those. Still it shouldn't sigsegv. + < braunr> gnumach is picky about that + < braunr> and yes, the hurd shouldn't have bugs + < zyg> braunr: ready to crash? #include #include int + main (int argc, char **argv) { mmap(0x10000, 0x8000, PROT_READ, MAP_ANON + | MAP_FIXED, -1, 0); return 0; } + < braunr> a fixed mapping at such an address is likely to fail, yes + < braunr> but a crash, hm + < zyg> why should it fail? + < braunr> because the hurd doesn't have a common text data bss heap stack + layout + < braunr> e.g. there are mappings below text, as show by vminfo : + < braunr> $ vminfo $$ + < braunr> 0[0x1000] (prot=0) + < braunr> 0x1000[0x21000] (prot=RX, max_prot=RWX, mem_obj=105) + < braunr> 0x22000[0x1000] (prot=R, max_prot=RWX, mem_obj=105) + < braunr> 0x23000[0x1000] (prot=RW, max_prot=RWX, mem_obj=105) + < braunr> 0x24000[0x1000] (prot=0, max_prot=RWX) + < braunr> 0x25000[0xfff000] (prot=RWX, mem_obj=106) + < braunr> 0x1024000[0x1000] (prot=RWX, mem_obj=107) + < braunr> 0x1025000[0x1000] (prot=RW, max_prot=RWX, mem_obj=108) + < braunr> 0x1026000[0x1000] (prot=RW, max_prot=RWX, mem_obj=108, + offs=0x1000) + < braunr> 0x1027000[0x1000] (prot=RW, max_prot=RWX, mem_obj=109) + < braunr> 0x1028000[0x2000] (prot=RW, max_prot=RWX, mem_obj=110, + offs=0x1000) + < braunr> 0x102a000[0x1000] (prot=RW, max_prot=RWX, mem_obj=111) + < braunr> (sorry for the long paste) + < zyg> oh.. my mmap falls into an occupied range? + < braunr> seems so + < zyg> thanks, that was really useful. + < braunr> MAP_FIXED isn't portable, this is clearly stated in most man + pages + < zyg> yes, implementation specific it says + < braunr> well the behaviour isn't specific, it's well defined, but the + memory layout isn't + < braunr> i personally think vm_map() should be slightly changed to include + a new flag for top-down allocations + < braunr> so that our stack and libraries are at high addresses, below the + kernel + < braunr> zyg: what kind of error do you get ? i don't get sigsegv + < zyg> I get both sigsegv and sigill depending on addr + < braunr> ok + < braunr> i get sigill with your example + < braunr> the error is the same (wrong memory access) but the behaviour + changes because of the special memory configuration + < zyg> yes.. I guess the usecase is too uncommon. Else mmap would have an + guard + < braunr> some accesses cause invalid page faults (which are sent as + segmentation faults) while other cause general protection faults (which + are sent as illegal instructions) + < braunr> (this is quite weird since the GP fault is likely because the + access targets something out of the data or code segment eh) + < zyg> braunr: that's very os-specific. Do you mean hurd behaves that way? + < braunr> gnumach + < braunr> on i386 + < braunr> the segmant configuration isn't completely flat + < braunr> segment* + < braunr> hm nice + < braunr> your small program triggers the "task X deallocating an invalid + port Y, most probably a bug." message + < zyg> where do you see that? + < braunr> on the mach console diff --git a/open_issues/multiprocessing.mdwn b/open_issues/multiprocessing.mdwn index 224c0826..562ccd83 100644 --- a/open_issues/multiprocessing.mdwn +++ b/open_issues/multiprocessing.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!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 @@ -8,7 +8,7 @@ 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]] +[[!tag open_issue_documentation open_issue_hurd]] We would expect that fine-grained, compartmentalized systems, that is, microkernel-based multi-server systems in particular, would be ideal candidates @@ -16,7 +16,7 @@ for applying multiprocessing. That is, however, only true from a first and inexperienced point of view: there are many difficulties. -IRC, #hurd, August / September 2010 +IRC, freenode, #hurd, August / September 2010 silver_hook: because multi-server systems depend on inter-process communication, and inter-process communication is many times more @@ -31,6 +31,37 @@ IRC, #hurd, August / September 2010 serious research challenges +IRC, freenode, #hurd, 2011-07-26 + + < braunr> 12:03 < CTKArcher> and does the hurd take more advantages in a + multicore architecture than linux ? + < braunr> CTKArcher: short answer: no + < CTKArcher> it's easier to imagine one server pro core than the linux + kernel divided to be executed on multiple cores + < braunr> CTKArcher: this approach is less efficient + < braunr> CTKArcher: threads carry state, both explicit and implicit (like + cache data) + < braunr> CTKArcher: switching to another core means resetting and + refetching this state + < braunr> it's expensive and there is no gain obtained by doing this + < braunr> thread migration (having a thread from a client also run in + servers when making synchronous RPC, even handling its own page faults) + was implemented in mach4 and is imo a very good thing we should have + < braunr> CTKArcher: and concerning linux, it's actually very scalable + < braunr> it's already like if all client threads run in servers (the + kernel is the servers there) + < braunr> rcu is used a lot + < braunr> thread migration already takes into account smt, cores, and numa + < braunr> it's hard to do something better + < braunr> (here, thread migration means being dispatched on another cpu) + < braunr> some systems like dragonflybsd go as far as to pin threads on one + processor for their entire lifetime + < braunr> in order to have rcu-like locking almost everywhere + < braunr> (you could argue it's less efficient since in the worst case + everything runs on the same cpu, but it's very unlikely, and in practice + most patterns are well balanced) + + debian-hurd list On Thu, Jan 02, 2003 at 05:40:00PM -0800, Thomas Bushnell, BSG wrote: diff --git a/open_issues/packaging_libpthread.mdwn b/open_issues/packaging_libpthread.mdwn index 7594ae76..fa3d4312 100644 --- a/open_issues/packaging_libpthread.mdwn +++ b/open_issues/packaging_libpthread.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!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 @@ -15,6 +15,9 @@ IRC, #hurd, 2010-07-31 My idea was to have a separate libpthread package. What do you think about that? in the long term, that can't work with glibc because of the thread stub stuff + +[[libpthread_dlopen]], for example. + it's not really possible to keep synchronized because you have to decide which package you unpack first (when upgrading) diff --git a/open_issues/performance.mdwn b/open_issues/performance.mdwn index eb9f3f8a..54f3ce39 100644 --- a/open_issues/performance.mdwn +++ b/open_issues/performance.mdwn @@ -26,3 +26,7 @@ severe performance degradation. For example, in this [[`fork` system call|/glibc/fork]]'s case. [[Unit_testing]] can be used for tracking performance regressions. + +--- + + * [[Degradation]] diff --git a/open_issues/performance/degradation.mdwn b/open_issues/performance/degradation.mdwn new file mode 100644 index 00000000..5db82e31 --- /dev/null +++ b/open_issues/performance/degradation.mdwn @@ -0,0 +1,28 @@ +[[!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="Degradation of GNU/Hurd ``system performance''"]] + +Email, *id:"87mxg2ahh8.fsf@kepler.schwinge.homeip.net"* (bug-hurd, 2011-07-25, +Thomas Schwinge) + +> Building a certain GCC configuration on a freshly booted system: 11 h. +> Remove build tree, build it again (2nd): 12 h 50 min. Huh. Remove build +> tree, reboot, build it again (1st): back to 11 h. Remove build tree, build +> it again (2nd): 12 h 40 min. Remove build tree, build it again (3rd): 15 h. + +IRC, freenode, #hurd, 2011-07-23 + + < antrik> tschwinge: yes, the system definitely gets slower with + time. after running for a couple of weeks, it needs at least twice as + long to open a new shell for example + < antrik> I don't know whether this is only related to swap usage, or there + are some serious fragmentation issues + < braunr> antrik: both could be induced by fragmentation diff --git a/open_issues/performance/io_system/binutils_ld_64ksec.mdwn b/open_issues/performance/io_system/binutils_ld_64ksec.mdwn index 79c2300f..359d5fee 100644 --- a/open_issues/performance/io_system/binutils_ld_64ksec.mdwn +++ b/open_issues/performance/io_system/binutils_ld_64ksec.mdwn @@ -33,3 +33,18 @@ the testee shows that (primarily) an ever-repeating series of `io_seek` and `io_read` is being processed. Running the testee on GNU/Linux with strace shows the equivalent thing (`_llseek`, `read`) -- but Linux' I/O system isn't as slow as the Hurd's. + +--- + +IRC, freenode, #hurd, 2011-09-01: + + hum, f951 does myriads of 71->io_seek_request (32768 0) = 0 32768 + no wonder it's slow + unfortunately that's also what it does on linux, the system call is + just less costly + apparently gfortran calls io_seek for, like, every token of the + sourced file + (fgetpos actually, but that's the same) + and it is indeed about 10 times slower under Xen for some reason + +[[!tag open_issue_xen]] diff --git a/open_issues/performance/microkernel_multi-server.mdwn b/open_issues/performance/microkernel_multi-server.mdwn new file mode 100644 index 00000000..111d2b88 --- /dev/null +++ b/open_issues/performance/microkernel_multi-server.mdwn @@ -0,0 +1,47 @@ +[[!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]] + +Performance issues due to the microkernel/multi-server system architecture? + +IRC, freenode, #hurd, 2011-07-26 + + < CTKArcher> I read that, because of its microkernel+servers design, the + hurd was slower than a monolithic kernel, is that confirmed ? + < youpi> the hurd is currently slower than current monolithic kernels, but + it's not due to the microkernel + servers design + < youpi> the microkernel+servers design makes the system call path longer + < youpi> but you're bound by disk and network speed + < youpi> so the extra overhead will not hurt so much + < youpi> except dumb applications keeping doing system calls all the time + of course, but they are usually considered bogus + < braunr> there may be some patterns (like applications using pipes + extensively, e.g. git-svn) which may suffer from the design, but still in + an acceptable range + < CTKArcher> so, you are saying that disk and network are more slowing the + system than the longer system call path and because of that, it wont + really matter ? + < youpi> braunr: they should sitll be fixed because they'll suffer (even if + less) on monolithic kernels + < youpi> CTKArcher: yes + < braunr> yes + < CTKArcher> mmh + < youpi> CTKArcher: you might want to listen to AST's talk at fosdem 10 + iirc, about minix + < youpi> they even go as far as using an IPC for each low-level in/out + < youpi> for security + < braunr> this has been expected for a long time + < braunr> which is what motivated research in microkernels + < CTKArcher> I've already downloaded the video :) + < youpi> and it has been more and more true with faster and faster cpus + < braunr> but in 95, processors weren't that fast compared to other + components as they are now + < youpi> while disk/mem haven't evovled so fast diff --git a/open_issues/proc_server_proc_exception_raise.mdwn b/open_issues/proc_server_proc_exception_raise.mdwn new file mode 100644 index 00000000..1d0e92a3 --- /dev/null +++ b/open_issues/proc_server_proc_exception_raise.mdwn @@ -0,0 +1,37 @@ +[[!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-08-11 + + < youpi> in which error cases a reply port will actually have been consumed + by mach_msg ? + < youpi> it seems at least MACH_SEND_NOTIFY_IN_PROGRESS do? + < braunr> + http://www.gnu.org/software/hurd/gnumach-doc/Message-Send.html#Message-Send + < braunr> "These return codes imply that the message was returned to the + caller with a pseudo-receive operation: " + < braunr> isn't it what you're looking for ? + < youpi> well, it's hard to tell from the name + < youpi> I don't know what "pseudo-receiv operation" means + < braunr> it's described below + < youpi> ew + < braunr> it looks close enough to a normal receive to assume it consumes + the reply port + < youpi> so it's even more complex than what I thought + < youpi> well, no, it returns the right + < youpi> actually the error I'm getting is MACH_RCV_INVALID_NAME + < youpi> which I guess means the sending part succeeded + < youpi> the case at stake is proc/mgt.c: S_proc_exception_raise() + < youpi> when the proc_exception_raise() forward fails + < youpi> currently we always return 0, but if proc_exception_raise() + actually managed to send the message, the reply port was consumed and + MIG_NO_REPLY should be returned instead diff --git a/open_issues/resource_management_problems.mdwn b/open_issues/resource_management_problems.mdwn index 760c7d66..1558bebb 100644 --- a/open_issues/resource_management_problems.mdwn +++ b/open_issues/resource_management_problems.mdwn @@ -61,7 +61,22 @@ This is, of course, non-trivial to implement, and also requires changing the SPLICE_F_GIFT flag](http://www.kernel.org/doc/man-pages/online/pages/man2/vmsplice.2.html#DESCRIPTION).) +IRC, freenode, #hurd, 2011-07-31 + + < braunr> one of the biggest problems on the hurd is that, when a client + makes a call, kernel (and other) resources are allocated on behalf of the + server performaing the requested action + < braunr> performing* + < braunr> this makes implementing scheduling and limits difficult + < CTKArcher> And could changing the kernel change anything to that ? + < braunr> yes but you'd probably need to change its interface as well + < braunr> iirc, the critique describes resource containers + < braunr> but no work has been done on the current hurd (hence the hurdng + attempts) + # Further Examples + * [[IO_accounting]] + * [[configure max command line length]] diff --git a/open_issues/resource_management_problems/io_accounting.mdwn b/open_issues/resource_management_problems/io_accounting.mdwn new file mode 100644 index 00000000..113b965a --- /dev/null +++ b/open_issues/resource_management_problems/io_accounting.mdwn @@ -0,0 +1,49 @@ +[[!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]]."]]"""]] + +IRC, freenode, #hurd, 2011-07-22 + + an interesting question i've had in mind for a few weeks now is + I/O accounting + what *is* I/O on a microkernel based system ? + can any cross address space transfer be classified as I/O ? + +IRC, freenode, #hurd, 2011-07-29 + + < braunr> how does the hurd account I/O ? + < youpi> I don't think it does + < youpi> not an easy task, actually + < youpi> since gnumach has no idea about it + < braunr> yes + < braunr> another centralization issue + < braunr> does network access count as I/O on linux ? + < youpi> no + < braunr> not even nfs ? + < youpi> else you'd get 100% for servers :) + < braunr> right + < youpi> nfs goes through vfs first + < braunr> i'll rephrase my question + < youpi> I'd need to check but I believe it can check nfs + < braunr> does I/O accounting occur at the vfs level or block layer ? + < youpi> I don't know, but I beleive vfs + < youpi> (at least that's how I'd do it) + < braunr> i don't have any more nfs box to test that :/ + < braunr> personally i'd do it at the block layer :) + < youpi> well, both + < youpi> so e2fsck can show up too + < braunr> yes + < youpi> it's just a matter of ref counting + < youpi> apparently nfs doesn't account + < youpi> find . -printf "" doesn't show up in waitio + < braunr> good + < youpi> well, depends on the point of view + < youpi> as a user, you'd like to know whether your processes are stuck on + i/o (be it disk or net) + < braunr> this implies clearly defining what io is diff --git a/open_issues/sa_siginfo_sa_sigaction.mdwn b/open_issues/sa_siginfo_sa_sigaction.mdwn index d6199b6a..3b8edff7 100644 --- a/open_issues/sa_siginfo_sa_sigaction.mdwn +++ b/open_issues/sa_siginfo_sa_sigaction.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!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 @@ -45,3 +45,50 @@ IRC, #hurd, August / September 2010: (i.e. replace with 0 in your example) ok when SA_SIGINFO becomes available, it'll just be used + +IRC, freenode, #hurd, 2011-08-20: + + < youpi> erf, tcpwrappers will need si_pid + < jkoenig> I could implement it not too far away in the future, we just + need a version of msg_sig_post() with a siginfo argument or something. + < youpi> I can also see a lot of packages using SA_SIGINFO for no reason... + < youpi> (probably copy/pasty code) + < youpi> sa.sa_flags = SA_SIGINFO; + < youpi> sa.sa_handler = parse_config; + < youpi> void parse_config(int) + < youpi> yay + < youpi> if(siginf->si_signo == SIGXCPU) + < youpi> fprintf(stderr, "Exceeded CPU usage.\n"); + < youpi> ... + < youpi> jkoenig: actually most package don't actually use the SA_SIGINFO + they request... + < youpi> jkoenig: si_pid should get us almost all actually used coverage + < youpi> I've seen only one example using si_errno + < jkoenig> ok + < youpi> oh, it's actually supported by your patch + < youpi> (errno) + < jkoenig> but I guess since implementing si_pid will require a new RPC, we + might as well plan for the rest + < youpi> jkoenig: indeed + < jkoenig> youpi, hmm I doubt it's properly filled in in all circumstances? + < youpi> ok, well, we'll see + < pinotree> jkoenig: if it can be of help, boost::unit_test queries various + fields of siginfo_t depending on the signal + < pinotree> jkoenig: also, pulseaudio uses siginfo_t for remapping faulting + memory on SIGBUS + < jkoenig> pinotree, oh ok good to know + < pinotree> *faulty + < youpi> jkoenig: well, I guess you had checked that the si_addr field is + correct in a few simple testcase :) + < jkoenig> hmm I think so, yes + < jkoenig> I ran like, "* (char *) 0x12345678;" or something IIRC + < youpi> ok + < jkoenig> I seem to remember mach generated SIGBUS instead of SIGSEGV + depending on the upper bit, or something (I can't quite remember) + < jkoenig> but when sigsegv was generated si_addr was right. + < pinotree> jkoenig: (see boost/test/impl/execution_monitor.ipp in boost + sources) + < pinotree> maybe you can try the unit tests for boost::unit_tests, if any + :) + < pinotree> (while src/pulsecore/memtrap.c in PA) + * pinotree stops doing MrObvious™ diff --git a/open_issues/sbcl.mdwn b/open_issues/sbcl.mdwn new file mode 100644 index 00000000..4bbf92ef --- /dev/null +++ b/open_issues/sbcl.mdwn @@ -0,0 +1,31 @@ +[[!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_porting]] + +IRC, freenode, #hurd, 2011-08-12 + + < zyg> did the segment registers had any purpose? I see fs is set equal to + others, but on linux fs is 0 (atleast on this x86 box). + < braunr> zyg: it can be used by special applications like wine, yes + < zyg> braunr: thanks.. I'm reading up on linux actually. It seems gs can + be used for TLS, fs in syscall to pass userspace. + < braunr> zyg: why are you interested in that ? + < zyg> a native compiler under linux places assumptions on fs register. So + I'm trying to find out what it should do under gnumach/hurd. + < braunr> what compiler ? + < zyg> braunr: it's sbcl + < braunr> ok + < youpi> zyg: the same, basically + < zyg> ok.. looking at the code, I've remarked where it sets up FS, because + /usr/include/asm/ldt.h:struct user_desc is missing. I must search for the + equiv. + < youpi> zyg: mach/i386/mach_i386.h + < youpi> the descriptor structure diff --git a/open_issues/sendmsg_scm_creds.mdwn b/open_issues/sendmsg_scm_creds.mdwn index 2deec7e8..c613e21c 100644 --- a/open_issues/sendmsg_scm_creds.mdwn +++ b/open_issues/sendmsg_scm_creds.mdwn @@ -90,6 +90,10 @@ IRC, unknown channel, unknown date. yep ok, good :) +/!\ IRC, freenode, #hurd, 2011-08-11 + + < pinotree> (but that patch is lame) + --- See also [[pflocal_socket_credentials_for_local_sockets]] and [[pflocal_reauth]]. diff --git a/open_issues/syslog.mdwn b/open_issues/syslog.mdwn index 778933a7..5fec38b1 100644 --- a/open_issues/syslog.mdwn +++ b/open_issues/syslog.mdwn @@ -1,7 +1,45 @@ IRC, unknwon channel, unknown date. - scolobb: In wiki edit 60accafa79f645ae61b578403f7fc0c11914b725 I see that you intend(ed) to use syslog for logging debug messages. I thought I'd point you to http://lists.gnu.org/archive/html/bug-hurd/2007-02/msg00042.html -- no idea if that's still an issue or what went wrong at that time. Perhaps you can have a look? - tschwinge: Thanks for information! Currently I'm logging some debug messages to a simple file, but I'll now check whether the issue you've pointed out is still present. - tschwinge: I am getting absolutely abnormal results: when I call syslog() from a simple C program for the first time, the message goes to the system log. However, any further calls to syslog() do just nothing... I am able to send something to syslog only after reboot (it doesn't help if I restart syslogd). + scolobb: In wiki edit 60accafa79f645ae61b578403f7fc0c11914b725 + I see that you intend(ed) to use syslog for logging debug messages. I + thought I'd point you to + http://lists.gnu.org/archive/html/bug-hurd/2007-02/msg00042.html -- no + idea if that's still an issue or what went wrong at that time. Perhaps + you can have a look? + tschwinge: Thanks for information! Currently I'm logging some + debug messages to a simple file, but I'll now check whether the issue + you've pointed out is still present. + tschwinge: I am getting absolutely abnormal results: when I call + syslog() from a simple C program for the first time, the message goes to + the system log. However, any further calls to syslog() do just + nothing... I am able to send something to syslog only after reboot (it + doesn't help if I restart syslogd). +IRC, freenode, #hurd, 2011-08-08 + + < pinotree> wow, `logger` + a simple C udp server can cause havoc + < pinotree> youpi: ever seen something like + http://paste.debian.net/hidden/72cf4b77/ ? + < pinotree> and then also other servers (like pflocal, pfinet, few more) + start becoming crazy (using 100% cpu) + < youpi> nope + < pinotree> iirc in one of the few tries i got the message "Resource lost." + from the closed ssh connection + < pinotree> i was trying to see why syslog doesn't work, but this basically + surprised me... + < pinotree> oh, i found an apparently working syslog daemon + < pinotree> dsyslog + < gg0> have you tried syslog-ng? IIRC it writes in /var/log/messages by + default. + < pinotree> yeah, it seems to stop receiving messages are few + < pinotree> gg0: are you using syslog-ng? + < gg0> pinotree: I should fire hurd vm up. I seem I kept dirty-patched + busybox syslog, I don't even know if it works, at least it starts + http://bugs.debian.org/636162 + < pinotree> maintainer said "not really" + < gg0> well, if all other syslogs use shm and sems, they won't work too, + right? + < youpi> shm should work with the latest libc + < youpi> what won't is sysv sem + < youpi> (i.e. semget) diff --git a/open_issues/tty_activitiy_vs_disk_io.mdwn b/open_issues/tty_activitiy_vs_disk_io.mdwn new file mode 100644 index 00000000..26382d56 --- /dev/null +++ b/open_issues/tty_activitiy_vs_disk_io.mdwn @@ -0,0 +1,81 @@ +[[!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-07-25 + + < youpi> Mmm, typing something on the mach console triggers a write on the + disk + < youpi> because the /dev/console node gets updated + < youpi> I don't really see why + < youpi> (yes, just typing at the bash prompt, not even running something) + < youpi> typing during the sleep command (i.e. mere tty echo) doesn't + trigger it, however + < youpi> running bash's echo does trigger it + < braunr> during sleep, the glibc stream functions handle I/O, while with + bash, its readline takes care of it, right ? + < youpi> /bin/echo too + < youpi> during sleep it's the tty process which handles I/O + < braunr> the write may be due to a write time update on the inode + < braunr> modification* time + < youpi> probably yes, but how so? + < youpi> ext2fs is only supposed to pass the thing to the console + translator + < braunr> not sure + < youpi> actually, ext2fs even isn't supposed to come into play when it's + about typing at the bash prompt + < youpi> once it's opened, isn't the port for /dev/console supposed to be + directly to the translator there? + < braunr> i think so + < youpi> (s/tty/term/ in what I said) + < braunr> well, it's certain + < youpi> so I don't see how ext2fs can be triggered to write an atime or + mtime + < braunr> what does rpctrace say ? + < youpi> io_read_request and io_write_request + < youpi> braunr: it doesn't happen at the login prompt + < youpi> interestingly, atime is always 3-4 secs earlier than ctime & mtime + < youpi> doesn't happen with dash + < braunr> we should implement relatime and experiment with it + < braunr> it shouldn't be hard + < youpi> well, there's noatime already + < youpi> but my point is that this update shouldn't happen + < youpi> and I believe it's the source of the i_file_acl e2fsck warning + < braunr> i wasn't saying that concerning this problem, it was just a + separate idea (noatime is more problematic than relatime) + < braunr> and i agree, it shouldn't happen :) + < youpi> ok, it's set_node_times which gets called + +IRC, freenode, #hurd, 2011-07-27 + + < antrik> BTW, I'm not sure it's still relevant; but the reason accessing + translators such as the console modifies the underlying node is that most + stat information is generally passed through + < antrik> (in some cases it might be unintentional though, simply using the + default implementation from trivfs carelessly...) + < youpi> I know + < youpi> I've seen that in the code + < antrik> OK + < youpi> it is still relevant: I still find it useless to write it on the + disk + < youpi> though w uses it to show idle time over reboot + < braunr> is it useful to keep the information across reboots ? + < youpi> for some value of "useful" for w + < braunr> i wonder what would break if this was entierly kept in memory + < youpi> nothing, probably + < youpi> note that it doesn't overload ext2fs so much, it just adds a write + every ~5s + < youpi> (at worse, i.e. when keeping showing text, for instance) + < braunr> indeed, the behaviour seems the same on linux + < antrik> ah... that explains why the disk doesn't spin down while IRC is + active... always wondered about that :-) + < youpi> that's not very power-saving, yes + < youpi> well, we might want to put /dev on ram someday diff --git a/open_issues/user-space_device_drivers.mdwn b/open_issues/user-space_device_drivers.mdwn index b8061f71..e929f2bf 100644 --- a/open_issues/user-space_device_drivers.mdwn +++ b/open_issues/user-space_device_drivers.mdwn @@ -33,6 +33,16 @@ Also see [[device drivers and IO systems]]. to IRQs. However, at least in GNU Mach, that code (`kern/eventcount.c`) doesn't seem functional at all and isn't integrated properly in the kernel. + * IRC, freenode, #hurd, 2011-07-29 + + < antrik> regarding performance of userspace drivers, there is one + thing that really adds considerable overhead: interrupt + handling. whether this is relevant very much depends on the hardware + in question. when sending many small packets over gigabit ethernet, + it might be noticable; in most other cases it's irrelevant + < youpi> some cards support interrupt coalescin + < youpi> could be supported by DDE too + ## DMA * Security considerations. @@ -52,6 +62,32 @@ Also see [[device drivers and IO systems]]. * [[GNU Mach|microkernel/mach/gnumach]] is said to have a high overhead when doing RPC calls. +## System Boot + +IRC, freenode, #hurd, 2011-07-27 + + < braunr> btw, was there any formulation of the modifications required to + have disk drivers in userspace ? + < braunr> (which would obviously need something like + initrd/initramfs/whatever and may also need the root file system not to + be the first task started) + < braunr> hm actually, we may not need initrd + < braunr> the boot loader could just load more modules + < antrik> braunr: I have described all that in my thesis report... in + German :-( + < braunr> and the boot scripts could be adjusted to pass around the right + ports + < Tekk_> braunr: yeah, we could probably load a module that kciks us into + userspace and starts the disk driver + < braunr> modules are actualy userspace executables + < Tekk_> ah + < Tekk_> so what's the issue? + < Tekk_> oh! I'm thinking the ext2fs server, which is already in userspce + < braunr> change the file systems to tell them which underlying disk driver + to use + < Tekk_> mhm + < braunr> s/disk/storage/ + # Plan diff --git a/open_issues/wine.mdwn b/open_issues/wine.mdwn index 85d35c9c..65e6c584 100644 --- a/open_issues/wine.mdwn +++ b/open_issues/wine.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!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 @@ -19,3 +19,51 @@ requirements Wine has: only libc / POSIX / etc., or if there are [[Samuel|samuelthibault]] suspects that *there's some need for LDT table allocation. There is kernel support for this,* however. + + +IRC, freenode, #hurd, 2011-08-11 + + < arethusa> I've been trying to make Wine work inside a Debian GNU/Hurd VM, + and to that end, I've successfully compiled the latest sources from Git + after installing the libc (devel) packages from experimental and + personally patching Wine with http://pastebin.com/rg6dx09G + +[[rg6dx09G.patch]] + + < arethusa> my question is, when trying to launch Wine, I'm seeing "wine + client error:0: sendmsg: (os/kern) invalid address" from the client side, + whereas the wineserver seems to be starting and running correctly, how + could I debug this issue further? using rpctrace doesn't seem to help, as + the trace just hangs when run on the Wine loader instead of yielding + insight + < kilobug> arethusa: isn't there a wine debuguer that can start a gdb when + wine encounters an error or something like that ? + < arethusa> it's too early for that + < kilobug> or least give you a full traceback of the wine code where the + error occur ? + < arethusa> the error is happening during initial connect to the + wineserver, in dlls/ntdll/server.c + < arethusa> but that doesn't help me figure out why sendmsg would error out + in this way + < arethusa> + http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ntdll/server.c#l361 + < azeem_> arethusa: probably some of the msghdr entries are not supported + by the Hurd's glib + < azeem_> c + < pinotree> haha, socket credentials, which we don't support yet + < azeem_> yep + < pinotree> youpi: ↑ another case ;) + < azeem_> arethusa: just implement those and it should work + < kilobug> in pflocal ? or glibc ? + < pinotree> pflocal + < arethusa> azeem_: hmm, okay, thanks + < pinotree> arethusa: their lack is a known issue, and makes things like + dbus and gamin not work + < arethusa> it's + https://www.gnu.org/software/hurd/open_issues/sendmsg_scm_creds.html and + related links I assume? + +[[sendmsg_scm_creds]] + + < youpi> yes + < pinotree> (but that patch is lame) diff --git a/open_issues/wine/rg6dx09G.patch b/open_issues/wine/rg6dx09G.patch new file mode 100644 index 00000000..510ff23f --- /dev/null +++ b/open_issues/wine/rg6dx09G.patch @@ -0,0 +1,116 @@ +diff --git a/dlls/ntdll/directory.c b/dlls/ntdll/directory.c +index 42b3639..7484608 100644 +--- a/dlls/ntdll/directory.c ++++ b/dlls/ntdll/directory.c +@@ -3145,14 +3145,14 @@ static void WINAPI read_changes_user_apc( void *arg, IO_STATUS_BLOCK *io, ULONG + static NTSTATUS read_changes_apc( void *user, PIO_STATUS_BLOCK iosb, NTSTATUS status, void **apc ) + { + struct read_changes_info *info = user; +- char data[PATH_MAX]; ++ char data[4096]; + NTSTATUS ret; + int size; + + SERVER_START_REQ( read_change ) + { + req->handle = wine_server_obj_handle( info->FileHandle ); +- wine_server_set_reply( req, data, PATH_MAX ); ++ wine_server_set_reply( req, data, 4096 ); + ret = wine_server_call( req ); + size = wine_server_reply_size( reply ); + } +diff --git a/dlls/ntdll/signal_i386.c b/dlls/ntdll/signal_i386.c +index 6c8e8e2..e949227 100644 +--- a/dlls/ntdll/signal_i386.c ++++ b/dlls/ntdll/signal_i386.c +@@ -180,6 +180,36 @@ __ASM_GLOBAL_FUNC(vm86_enter, + + #endif /* linux */ + ++#ifdef __GNU__ ++ ++typedef ucontext_t SIGCONTEXT; ++ ++#define EAX_sig(context) ((context)->uc_mcontext.gregs[REG_EAX]) ++#define EBX_sig(context) ((context)->uc_mcontext.gregs[REG_EBX]) ++#define ECX_sig(context) ((context)->uc_mcontext.gregs[REG_ECX]) ++#define EDX_sig(context) ((context)->uc_mcontext.gregs[REG_EDX]) ++#define ESI_sig(context) ((context)->uc_mcontext.gregs[REG_ESI]) ++#define EDI_sig(context) ((context)->uc_mcontext.gregs[REG_EDI]) ++#define EBP_sig(context) ((context)->uc_mcontext.gregs[REG_EBP]) ++#define ESP_sig(context) ((context)->uc_mcontext.gregs[REG_ESP]) ++ ++#define CS_sig(context) ((context)->uc_mcontext.gregs[REG_CS]) ++#define DS_sig(context) ((context)->uc_mcontext.gregs[REG_DS]) ++#define ES_sig(context) ((context)->uc_mcontext.gregs[REG_ES]) ++#define SS_sig(context) ((context)->uc_mcontext.gregs[REG_SS]) ++#define FS_sig(context) ((context)->uc_mcontext.gregs[REG_FS]) ++#define GS_sig(context) ((context)->uc_mcontext.gregs[REG_GS]) ++ ++#define EFL_sig(context) ((context)->uc_mcontext.gregs[REG_EFL]) ++#define EIP_sig(context) ((context)->uc_mcontext.gregs[REG_EIP]) ++#define TRAP_sig(context) ((context)->uc_mcontext.gregs[REG_TRAPNO]) ++#define ERROR_sig(context) ((context)->uc_mcontext.gregs[REG_ERR]) ++ ++#define FPU_sig(context) ((FLOATING_SAVE_AREA *)&(context)->uc_mcontext.fpregs.fp_reg_set.fpchip_state) ++#define FPUX_sig(context) NULL ++ ++#endif /* __GNU__ */ ++ + #ifdef BSDI + + #include +diff --git a/dlls/shell32/shfldr_unixfs.c b/dlls/shell32/shfldr_unixfs.c +index 9649df8..cdd1798 100644 +--- a/dlls/shell32/shfldr_unixfs.c ++++ b/dlls/shell32/shfldr_unixfs.c +@@ -369,7 +369,7 @@ static inline BOOL UNIXFS_is_pidl_of_type(LPCITEMIDLIST pIDL, SHCONTF fFilter) { + static BOOL UNIXFS_get_unix_path(LPCWSTR pszDosPath, char *pszCanonicalPath) + { + char *pPathTail, *pElement, *pCanonicalTail, szPath[FILENAME_MAX], *pszUnixPath, has_failed = 0, mb_path[FILENAME_MAX]; +- WCHAR wszDrive[] = { '?', ':', '\\', 0 }, dospath[PATH_MAX], *dospath_end; ++ WCHAR wszDrive[] = { '?', ':', '\\', 0 }, dospath[MAX_PATH], *dospath_end; + int cDriveSymlinkLen; + void *redir; + +diff --git a/dlls/winex11.drv/xrender.c b/dlls/winex11.drv/xrender.c +index ad8e08b..a8d6329 100644 +--- a/dlls/winex11.drv/xrender.c ++++ b/dlls/winex11.drv/xrender.c +@@ -2440,8 +2440,8 @@ void X11DRV_XRender_UpdateDrawable(X11DRV_PDEVICE *physDev) + return; + } + +-BOOL XRender_AlphaBlend( X11DRV_PDEVICE *devDst, X11DRV_PDEVICE *devSrc, +- struct bitblt_coords *dst, struct bitblt_coords *src, BLENDFUNCTION blendfn ) ++BOOL XRender_AlphaBlend( X11DRV_PDEVICE *devDst, struct bitblt_coords *dst, ++ X11DRV_PDEVICE *devSrc, struct bitblt_coords *src, BLENDFUNCTION blendfn ) + { + FIXME("not supported - XRENDER headers were missing at compile time\n"); + return FALSE; +diff --git a/libs/wine/ldt.c b/libs/wine/ldt.c +index 3098061..b3fee13 100644 +--- a/libs/wine/ldt.c ++++ b/libs/wine/ldt.c +@@ -96,6 +96,11 @@ static inline int set_thread_area( struct modify_ldt_s *ptr ) + #include + #endif + ++#ifdef __GNU__ ++#include ++#include ++#endif ++ + /* local copy of the LDT */ + #ifdef __APPLE__ + struct __wine_ldt_copy wine_ldt_copy = { { 0, 0, 0 } }; +@@ -203,6 +208,9 @@ static int internal_set_entry( unsigned short sel, const LDT_ENTRY *entry ) + #elif defined(__APPLE__) + if ((ret = i386_set_ldt(index, (union ldt_entry *)entry, 1)) < 0) + perror("i386_set_ldt"); ++#elif defined(__GNU__) ++ if ((ret = i386_set_ldt(mach_thread_self(), sel, (descriptor_list_t)entry, 1)) != KERN_SUCCESS) ++ perror("i386_set_ldt"); + #else + fprintf( stderr, "No LDT support on this platform\n" ); + exit(1); \ No newline at end of file -- cgit v1.3.1 From c13fc001dbf8b9da4ebf730761fc7b8c1f017c56 Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Tue, 6 Sep 2011 19:35:32 +0200 Subject: Mention EPT acceleration --- hurd/running/qemu.mdwn | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'hurd') diff --git a/hurd/running/qemu.mdwn b/hurd/running/qemu.mdwn index 343707fa..77bfc977 100644 --- a/hurd/running/qemu.mdwn +++ b/hurd/running/qemu.mdwn @@ -105,6 +105,12 @@ kernels, compared to 2.6.32: [[!debbug 634149]]. We're preparing on a change on our side to work around this. +# EPT acceleration + +Performance will be yet better if EPT is available: + + $ grep ept /proc/cpuinfo + # Installing Debian/Hurd with QEMU using the Debian installer Note: If you have hardware support, replace the qemu commands below with kvm, e.g. qemu-ing -> kvm-img. -- cgit v1.3.1 From 06ffbd53565f806795f6b44c5b73b6c14b60368d Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Wed, 7 Sep 2011 01:57:08 +0200 Subject: Add amd name --- hurd/running/qemu.mdwn | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'hurd') diff --git a/hurd/running/qemu.mdwn b/hurd/running/qemu.mdwn index 77bfc977..b2812750 100644 --- a/hurd/running/qemu.mdwn +++ b/hurd/running/qemu.mdwn @@ -105,11 +105,12 @@ kernels, compared to 2.6.32: [[!debbug 634149]]. We're preparing on a change on our side to work around this. -# EPT acceleration +# HAP/EPT/NPT acceleration -Performance will be yet better if EPT is available: +Performance will be yet better if HAP (EPT or NPT) is available: $ grep ept /proc/cpuinfo + $ grep npt /proc/cpuinfo # Installing Debian/Hurd with QEMU using the Debian installer -- cgit v1.3.1 From 9a5d1e0a092d6cd09eff0d7f04969983789d4128 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sat, 17 Sep 2011 01:10:02 +0200 Subject: hurd/running/debian/patch_submission: Make the pseudo-headers easily copy & pasteable. --- hurd/running/debian/patch_submission.mdwn | 22 +++++++++++++--------- 1 file changed, 13 insertions(+), 9 deletions(-) (limited to 'hurd') diff --git a/hurd/running/debian/patch_submission.mdwn b/hurd/running/debian/patch_submission.mdwn index d2b7b776..1dd8a4db 100644 --- a/hurd/running/debian/patch_submission.mdwn +++ b/hurd/running/debian/patch_submission.mdwn @@ -28,20 +28,24 @@ either use the reportbug tool, or just simple mail. In any case, you should follow these guidelines: * The submission address is . + * The mail's subject (which will become the bug's title) should be `SOURCE-PACKAGE: FTBFS on hurd-i386: REASON`. - * The first lines of the mail's body (the so-called *pseudo-header*): - * `Severity: important` -- not *serious*. - * `Version: VERSION` -- the version of the source package in unstable. - * `Tags: patch` -- as/if you include a ready-to-be-applied patch. - * `User: debian-hurd@lists.debian.org` - * `Usertags: hurd` -Please also add + * The first lines of the mail's body (the so-called *pseudo-header*): -`X-Debbugs-CC: debian-hurd@lists.debian.org` + Package: PACKAGE + Severity: important -- not *serious* + Version: VERSION -- the version of the source package in unstable. + Tags: patch -- if you include a ready-to-be-applied patch. + User: debian-hurd@lists.debian.org + Usertags: hurd + X-Debbugs-CC: debian-hurd@lists.debian.org -in the mail headers, so that the mailing list knows about your report. +The last three lines are used to to change the current *User* to the specified +value (the default is the email sender/from address), specify *Usertags* to add +the specified tags for the current user, and *X-Debbugs-CC* so that the +[[mailing list|mailing_lists/debian-hurd]] knows about your report. In the bug description, mention that the package fails to build on hurd-i386 and (if possible) quote the failure. If possible, point to the failing build -- cgit v1.3.1 From 1323558c37c04d599fe5fd8e2d058f196af360e7 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sat, 17 Sep 2011 11:38:53 +0200 Subject: open_issues/glibc: New. --- .../testing_framework/discussion.mdwn | 4 +- community/gsoc/project_ideas/testsuites.mdwn | 2 +- glibc.mdwn | 3 + glibc/discussion.mdwn | 2 +- hurd/debugging/glibc.mdwn | 8 +- open_issues/glibc.mdwn | 477 +++++++++++++++++++++ open_issues/glibc/debian.mdwn | 46 ++ open_issues/glibc_testsuite.mdwn | 105 ----- open_issues/unit_testing.mdwn | 4 +- 9 files changed, 537 insertions(+), 114 deletions(-) create mode 100644 open_issues/glibc.mdwn create mode 100644 open_issues/glibc/debian.mdwn delete mode 100644 open_issues/glibc_testsuite.mdwn (limited to 'hurd') diff --git a/community/gsoc/project_ideas/testing_framework/discussion.mdwn b/community/gsoc/project_ideas/testing_framework/discussion.mdwn index 872d0eb7..b01d13c3 100644 --- a/community/gsoc/project_ideas/testing_framework/discussion.mdwn +++ b/community/gsoc/project_ideas/testing_framework/discussion.mdwn @@ -8,6 +8,8 @@ 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]] + freenode, #hurd channel, 2011-03-05: what about testing though? @@ -50,7 +52,7 @@ freenode, #hurd channel, 2011-03-05: AFAIK libc has very few failing tests -[[open_issues/glibc_testsuite]]. +[[open_issues/glibc]]. err, like twenty? € grep -v '^#' expected-results-i486-gnu-libc | wc -l diff --git a/community/gsoc/project_ideas/testsuites.mdwn b/community/gsoc/project_ideas/testsuites.mdwn index f5ee2084..9ca6fe3e 100644 --- a/community/gsoc/project_ideas/testsuites.mdwn +++ b/community/gsoc/project_ideas/testsuites.mdwn @@ -11,7 +11,7 @@ License|/fdl]]."]]"""]] [[!meta title="Fix Compatibility Problems Exposed by Testsuites"]] A number of software packages come with extensive testsuites. -Some notable ones are [[glibc|open_issues/glibc_testsuite]], gnulib, Perl, +Some notable ones are [[open_issues/glibc]], gnulib, Perl, Python, GNU Coreutils, and glib. While these testsuites were written mostly to track regressions in the respective packages, some of the tests fail on the Hurd in general. diff --git a/glibc.mdwn b/glibc.mdwn index 936bf0c2..54a0e19f 100644 --- a/glibc.mdwn +++ b/glibc.mdwn @@ -34,6 +34,9 @@ This is different to the Linux port, where most simple POSIX interfaces are in fact simply forwarded to/implemented as [[system_call]]s. +## [[Maintenance|open_issues/glibc]] + + # Implementation Details * [[hurd/glibc/Hurd-specific API]] diff --git a/glibc/discussion.mdwn b/glibc/discussion.mdwn index 17b4fb32..fac300ea 100644 --- a/glibc/discussion.mdwn +++ b/glibc/discussion.mdwn @@ -14,7 +14,7 @@ License|/fdl]]."]]"""]] ## IRC, freenode, #hurd, 2011-06-11 -[[!tag open_issue_documentation]] +[[!tag open_issue_documentation open_issue_glibc]] youpi: local-tls-support.diff removes libc-tsd.h; what's the rationale? diff --git a/hurd/debugging/glibc.mdwn b/hurd/debugging/glibc.mdwn index e9817132..028d4fe4 100644 --- a/hurd/debugging/glibc.mdwn +++ b/hurd/debugging/glibc.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2007, 2008, 2010 Free Software Foundation, +[[!meta copyright="Copyright © 2007, 2008, 2010, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -6,8 +6,8 @@ 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] Here are some hints about how to approach testing after nontrivial changes to glibc have been done. @@ -29,7 +29,7 @@ newly created libraries and loader actually work: they'll be used to run the Unless cross-compiling, the next thing you'll probably want to do is running the test suite, or parts of it. -There is a list of [[known failures|open_issues/glibc_testsuite]]. +There is a list of [[known failures|open_issues/glibc]]. --- diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn new file mode 100644 index 00000000..cb56529a --- /dev/null +++ b/open_issues/glibc.mdwn @@ -0,0 +1,477 @@ +[[!meta copyright="Copyright © 2007, 2008, 2010, 2011 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc]] + +Here's what's to be done for maintaining glibc. + +[[!toc levels=2]] + + +# [[General information|/glibc]] + + +# [[Sources|source_repositories/glibc]] + + +# [[Debian]] Cheat Sheet + + +# Configuration + +Last reviewed up to the [[Git mirror's 9f94d2ea71aaf73f964f8c1de5da85df94ef25bb +(2011-01-19) sources|source_repositories/glibc]]. + + * t/dup3 + + [[tschwinge]] is not convinced that + 22542dcc89805af8d9bd9209129259d2737372b5 (and then also + ff3f3a789ba08b656dbaa3901091b6410bb883f8) are correct. + + * t/init-first.c + + Have to revert 53b56b1101fc9bb4f295f23f54e7e19f8da8da16 to keep it working + with GCC 4.4. Figure out what's going on. + + * t/tls + + * Discuss d2431f633e6139a62e1575ec18830f7e81160cf0 with Samuel. + + * `TLS_INIT_TP_EXPENSIVE` is unused; Hurd def. can be removed. + + * [[toolchain/cross-gnu]], without `--disable-multi-arch` + + i686-pc-gnu-gcc ../sysdeps/i386/i686/multiarch/strcmp.S -c [...] + ../sysdeps/i386/i686/multiarch/../strcmp.S: Assembler messages: + ../sysdeps/i386/i686/multiarch/../strcmp.S:31: Error: symbol `strcmp' is already defined + make[2]: *** [/media/boole-data/thomas/tmp/gnu-0/src/glibc.obj/string/strcmp.o] Error 1 + make[2]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/glibc/string' + + Might simply be a missing patch(es) from master. + + * --build=X + + `long double` test: due to `cross_compiling = maybe` wants to execute a + file, which fails. Thus `--build=X` has to be set. + + * Check what all these are: + + running configure fragment for sysdeps/mach/hurd + checking Hurd header version... ok + running configure fragment for sysdeps/mach + checking for i586-pc-gnu-mig... i586-pc-gnu-mig + checking for mach/mach_types.h... yes + checking for mach/mach_types.defs... yes + checking for task_t in mach/mach_types.h... task_t + checking for thread_t in mach/mach_types.h... thread_t + checking for creation_time in task_basic_info... yes + checking for mach/mach.defs... yes + checking for mach/mach4.defs... yes + checking for mach/clock.defs... no + checking for mach/clock_priv.defs... no + checking for mach/host_priv.defs... no + checking for mach/host_security.defs... no + checking for mach/ledger.defs... no + checking for mach/lock_set.defs... no + checking for mach/processor.defs... no + checking for mach/processor_set.defs... no + checking for mach/task.defs... no + checking for mach/thread_act.defs... no + checking for mach/vm_map.defs... no + checking for mach/memory_object.defs... yes + checking for mach/memory_object_default.defs... yes + checking for mach/default_pager.defs... yes + checking for mach/i386/mach_i386.defs... yes + checking for egrep... grep -E + checking for host_page_size in mach_host.defs... no + checking for mach/machine/ndr_def.h... no + checking for machine/ndr_def.h... no + checking for i386_io_perm_modify in mach_i386.defs... yes + checking for i386_set_gdt in mach_i386.defs... yes + checking whether i586-pc-gnu-mig supports the retcode keyword... yes + + * `make` has rebuilt `configure`, then: + + -checking whether ranlib is necessary... no + +checking whether ranlib is necessary... yes + + Very likely due to (improper) caching. But ranlib will be removed in a + later sourceware master commit. + + * `elf/stackguard-macros.h` + + * Verify 77c84aeb81808c3109665949448dba59965c391e against + `~/shared/glibc/make_TAGS.patch`. + + * `HP_SMALL_TIMING_AVAIL` not defined anywhere. + + * Unify `CPUCLOCK_WHICH` stuff in `clock_*` files. + + * Not all tests are re-run in a `make -k tests; make tests-clean; make -k + tests` cycle. + + * `CPUCLOCK_WHICH`, `t/cpuclock` + + /media/boole-data/thomas/tmp/gnu-0/src/glibc.obj/rt/librt_pic.a(clock_settime.os): In function `clock_settime': + /media/boole-data/thomas/tmp/gnu-0/src/glibc/rt/../sysdeps/unix/clock_settime.c:113: undefined reference to `CPUCLOCK_WHICH' + /media/boole-data/thomas/tmp/gnu-0/src/glibc/rt/../sysdeps/unix/clock_settime.c:114: undefined reference to `CPUCLOCK_WHICH' + collect2: error: ld returned 1 exit status + make[2]: *** [/media/boole-data/thomas/tmp/gnu-0/src/glibc.obj/rt/librt.so] Error 1 + make[2]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/glibc/rt' + make[1]: *** [rt/others] Error 2 + make[1]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/glibc' + make: *** [all] Error 2 + + * verify baseline changes, if we need any follow-up changes + + * a11ec63713ea3903c482dc907a108be404191a02 + * 7e2b0c8562b35155820f87b5ff02a8b6850344cc + * 8c0677fe5d91b7269364ca08fa08ed09e4c2d8c9 + * 5a2a1d75043138e696222ced4560de2fb90b8024 + * 5ae958d74180e2572d198bd7872c86f391de6da7 + * 5b08ac571ff8e94fe96511a532f0d20997de5f52 + * 3d04ff3a5d3ce3616837e1d15e03b6e1b360cf26 + * b2ef2c014b9c66995a3eb4f310ae7c5c510279bf + * 63c4ed22b5048c8701d8806026c23cc95f0df756 + * ac2b484c02b01307ab6bbe5d45ddbf16d64edf8c + * e35fcef8b739ed24e083ff8a3078ac14e101cf67 + * 6fb8cbcb58a29fff73eb2101b34caa19a7f88eba + * 8a492a675e566dc1e666df0a86cbf541442cb179 + * 5dbc3b6cc0b759bf4b22d851ccb9cbf3e3cbc6ef + * c86434ccb576a3ce35b5a74f72b9f03bd45b522a + * d22e4cc9397ed41534c9422d0b0ffef8c77bfa53 + * 15bac72bac03faeb3b725b1d208c62160f0c3ad7 + * c08fb0d7bba4015078406b28d3906ccc5fda9d5a + * 10b3bedcb03386cc280113f552479793e4bac35f + * 754f7da38b0904b4b989d3500cc8dd5be625cf6a + * 3cdaa6adb113a088fdfb87aa6d7747557eccc58d + * 962dba7828cf251a9025ccb43bc6effa30379b72 + * 3162f12e58c3a848db883916843b332b9f8c9d39 + * 1c06ba3100847da6bd1f2e011dc24fa8debd9615 + * 84b9230c404aed4fd3a7bb3d045ca367043dde8c + * 090555538d4347a52807ba9f08cf20ed13206afe + * 817328eea788c746131cf151b64fd250200da333 + * c3758feebf7c8786231465da664743c6f0ec79cc + * 1ac7a2c7b448c851eb8976fcc290a906a4075203 + * c21cc9bcb38a87ff638d1099ca871d94a2192b31 + * 6484ba5ef092b62b7d2112c0d976dbd6d1a40fde + * b8b4863d78bf26b39918fc753b03ed98ef262903 + * b76b818e6fe2061e778b3a9bbe63c554c3f9b3c1 + * 8e9f92e9d5d7737afdacf79b76d98c4c42980508 -- `_dl_map_object` in + `sysdeps/mach/hurd/dl-sysdep.c` + * 0e516e0e14f2f9783a21cd1727bc53776341f857 + * a1fb5e3ebe9d38b5ae6c5bfbfaa04882d52355bc + * cf7c9078a5acdbb435498ace92cd81009637a971 + * db753e2cfb2051ebf20dc089f87c5b1297cc2cff + * 4a531bb0b3b582cb693de9f76d2d97d970f9a5d5 -- looks good. + * 5bd6dc5c2c68fe98691db9b40f87d9b68ea9565b + * 451f001b50870604e1f2daef12f04f9f460d3997 + + a85b5cb4d4a5fc56e2b38638d270bf2daa67eb6c -- BZ10484. `nptl/Versions + [libc] (GLIBC_PRIVATE): Export __libc_alloca_cutoff`. We don't even + define it yet. + * 1086d70d916fd0eb969b3d89ff88abd35f6a5c34 + * cfa28e560ef69372b9e15e9a2d924a0fbcfc7bca + * 8cf8ce1702c354a8266e3cfa6ab54c2467d1873f + * 68dc949774cb651d53541df4abdc60327f7e096b + * 70181fddf1467996bea393d13294ffe76b8a0853 + * a77e8cbc394ab098aa1fc3f0a6645a38348d21ca + * 32465c3ea007065acd8ca8199f130cdf4068130d + * 18ba70a559c52719fd94a713cc380514d9d19125 + * 620a05296fe3380b7441ba7720e8b25c48a8c28c + + +# Build + +Here's a log of a glibc build run; this is from our [[Git repository's +d1517b24ef07438a09baf9fd512cc9defabbba2d (2011-09-17; 2011-01-19) +sources|source_repositories/glibc]], run on coulomb.SCHWINGE. + + $ export LC_ALL=C + $ ../Roger_Whittaker/configure --without-cvs --prefix=/usr --disable-profile --disable-multi-arch --build=i486-gnu --host=i486-gnu CC=gcc-4.4 CXX=g++-4.4 2>&1 | tee log_build + [...] + $ make 2>&1 | tee log_build_ + [...] + +This takes up around 400 MiB and needs roughly TODO min on coulomb.SCHWINGE. + + + + +## Analysis + +TODO. + + +# Install + +TODO. + + + + +## Analysis + +TODO. + + + + +# Testsuite + + $ make -k check 2>&1 | tee log_check + [...] + +This needs roughly 50 min on coulomb.SCHWINGE. + + + + +## Analysis + +This is from *2010-04* sources. + +There is quite a baseline of failures. + +### Additional Failures Compared to Debian + + $ bash ~/tmp/glibc/debian/eglibc-2.13/debian/testsuite-checking/convertlog.sh log_check > log_check.filtered + $ bash ~/tmp/glibc/debian/eglibc-2.13/debian/testsuite-checking/compare.sh ~/tmp/glibc/debian/eglibc-2.13/debian/testsuite-checking/expected-results-i486-gnu-libc log_check.filtered + + * `bug-atexit3.out`, `debug/tst-chk4`, `debug/tst-lfschk4`, + `debug/tst-lfschk5`, `debug/tst-lfschk6`, `debug/tst-chk5`, + `debug/tst-chk6` + + dlopen failed: libstdc++.so.6: cannot open shared object file: No such file or directory + + * `posix/bug-ga1` + + *** glibc detected *** /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486.O/posix/bug-ga1: free(): invalid pointer: 0x01026000 *** + + * `elf/circleload1`, `elf/loadtest`, `elf/neededtest`, `elf/neededtest2`, + `elf/neededtest3`, `elf/neededtest4`, `elf/unload`, `elf/unload2` + + /usr/bin/ld: ^Q: invalid DSO for symbol `_r_debug@@GLIBC_2.2.6' definition + /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486.O/elf/ld.so.1: could not read symbols: Bad value + collect2: ld returned 1 exit status + make[2]: *** [/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486.O/elf/circleload1] Error 1 + + * `io/ftwtest`, `posix/globtest`, `iconvdata/iconv-test`, `intl/tst-gettext`, + `malloc/tst-mtrace`, `elf/tst-pathopt`, `iconvdata/tst-tables`, + `grp/tst_fgetgrent`, `dlfcn/tststatic`, `dlfcn/tststatic2`, + `posix/wordexp-tst` + + /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486.O/io/ftwtest: error while loading shared libraries: libmachuser.so.1: cannot open shared object file: No such file or directory + + Should be using the build-directory one anyway! + + * `elf/noload` + + /usr/bin/ld: ^R: invalid DSO for symbol `dlclose@@GLIBC_2.2.6' definition + /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486.O/dlfcn/libdl.so.2: could not read symbols: Bad value + collect2: ld returned 1 exit status + make[2]: *** [/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486.O/elf/noload] Error 1 + + * `math/test-idouble`, `math/test-ifloat`, `math/test-ildoubl`, + `math/test-ldouble` + + SIGSEGV. + + * `rt/tst-aio10`, `rt/tst-aio9` + + /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486.O/rt/tst-aio10.o: In function `do_test': + tst-aio10.c:(.text+0x1b): undefined reference to `pthread_self' + tst-aio10.c:(.text+0x78): undefined reference to `pthread_barrier_init' + tst-aio10.c:(.text+0xf7): undefined reference to `pthread_create' + tst-aio10.c:(.text+0x10b): undefined reference to `pthread_barrier_wait' + /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486.O/rt/tst-aio10.o: In function `tf': + tst-aio10.c:(.text+0x5ae): undefined reference to `pthread_barrier_wait' + tst-aio10.c:(.text+0x5ef): undefined reference to `pthread_kill' + collect2: ld returned 1 exit status + make[2]: *** [/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486.O/rt/tst-aio10] Error 1 + + * `rt-tst-aio2`, `rt-tst-aio3`, `rt/tst-mqueue3`, `rt/tst-mqueue6`, + `rt/tst-mqueue8`, `elf/tst-thrlock`, `rt/tst-timer3` + + Compilation: missing `pthread_attr_init`, `pthread_barrier_init`, + `pthread_create`, etc. + + * `elf/tst-audit1`, `elf/tst-audit2` + + SIGKILL. + + * `inet/tst-ether_line` + + tst-ether_line.c:19: error: 'ETH_ALEN' undeclared (first use in this function) + + * `posix/tst-getaddrinfo`, `posix/tst-getaddrinfo2`, `posix/tst-getaddrinfo3` + + *** glibc detected *** /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486.O/posix/tst-getaddrinfo: free(): invalid pointer: 0x01026000 *** + Didn't expect signal from child: got `Aborted' + + * `posix/tst-getconf` + + /bin/sh -e tst-getconf.sh /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486.O/ /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486.O/elf/ ld.so.1 + make[2]: *** [/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486.O/posix/tst-getconf.out] Error 127 + + * `time/tst-mktime2` + + tst-mktime2.c:132: error: 'INT_MAX' undeclared (first use in this function) + + * `io/tst-readlinkat` + + /media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker/io/tst-readlinkat.c:109: warning: warning: readlinkat is not implemented and will always fail + + * `gmon/tst-sprofil` + + Floating point exception + + * `posix/tst-sysconf` + + tst-sysconf.c:32: error: '_POSIX_PRIORITIZED_IO' undeclared here (not in a function) + tst-sysconf.c:33: error: '_POSIX_PRIORITY_SCHEDULING' undeclared here (not in a function) + tst-sysconf.c:43: error: '_POSIX_SPIN_LOCKS' undeclared here (not in a function) + tst-sysconf.c:45: error: '_POSIX_SYNCHRONIZED_IO' undeclared here (not in a function) + + * `elf/tst-tls1`, `elf/tst-tls2`, `elf/tst-tls3` + + /usr/bin/ld: ^R: invalid DSO for symbol `___tls_get_addr@@GLIBC_2.3' definition + /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486.O/elf/ld.so.1: could not read symbols: Bad value + collect2: ld returned 1 exit status + make[2]: *** [/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486.O/elf/tst-tls3] Error 1 + + * `elf/tst-tls10`, `elf/tst-tls11`, `elf/tst-tls12` + + /usr/bin/ld: ^O: invalid DSO for symbol `f6a' definition + /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486.O/elf/tst-tlsmod7.so: could not read symbols: Bad value + collect2: ld returned 1 exit status + make[2]: *** [/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486.O/elf/tst-tls10] Error 1 + + +## OLD + +`configure --without-cvs --prefix= --disable-profile --build=i486-gnu +--host=i486-gnu` + +`make -k check` changes from 538603af899057a9ef9583cc447804ec602a45e5 to +c9fd33ef070def49c078c94f8d9bc9f8a8e267f7. + +Configured with `--prefix=/usr` instead of `--prefix=`. + +Resolved failures: + + * localedata/tst_mblen.out + * localedata/tst_mbrlen.out + * localedata/tst_mbrtowc.out + * localedata/tst_mbsrtowcs.out + * localedata/tst_mbstowcs.out + * localedata/tst_mbtowc.out + * localedata/tst_swscanf.out + * localedata/tst_wcrtomb.out + * localedata/tst_wcsrtombs.out + * localedata/tst_wcstombs.out + * localedata/tst_wctob.out + * localedata/tst_wctomb.out + * localedata/bug-iconv-trans.out + * localedata/tst-wctype.out + * math/test-float.out + * math/test-double.out + * posix/tst-vfork3-mem + * io/tst-mkdirat.out + +New: + + * A lot of `error while loading shared libraries: libmachuser.so.1: cannot + open shared object file: No such file or directory`. Is it perhaps picking + that library up from `$prefix/lib/`? + + New failures; likely due to that: + + * iconvdata/iconv-test.out + * iconvdata/tst-tables.out + * malloc/tst-mtrace.out + * grp/tst_fgetgrent.out + * posix/globtest.out + * posix/wordexp-tst.out + * io/ftwtest.out + * elf/tst-pathopt.out + + Changed failures; likely due to that: + + * debug/tst-chk4.out / debug/tst-chk5.out + + -error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory + +error while loading shared libraries: libpthread-stubs.so.0: cannot open shared object file: No such file or directory + +--- + +Changes to b367d4f996512af6841c3cefdb943cb0a826a6a1: nothing interesting. + +--- + +Changes to b85c54a1f7e5241c1ef99dfeaecbd1bf4117564f: nothing interesting. + +New failures: + + * posix/bug-glob3.out (SEGFAULT; but also on Linux) + * wctype/bug-wctypeh.o (compile error; but also on Linux) + +Other things noticed: + + * Running `make -k check` for the second time: + + -i486-gnu-gcc tst-timer2.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -g -Wno-parentheses -Wstrict-prototypes -mpreferred-stack-boundary=2 -I../include -I/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/rt -I/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build -I../sysdeps/i386/elf -I../sysdeps/mach/hurd/i386 -I../sysdeps/mach/hurd -I../sysdeps/gnu -I../sysdeps/unix/bsd/bsd4.4 -I../sysdeps/unix/mman -I../sysdeps/mach/i386 -I../sysdeps/mach -I../sysdeps/i386/i486 -I../sysdeps/i386/fpu -I../sysdeps/i386 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/unix/bsd -I../sysdeps/unix/common -I../sysdeps/unix/inet -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -I../hurd -I/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/hurd/ -I../mach -I/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/mach/ -I.. -I../libio -I. -D_LIBC_REENTRANT -include ../include/libc-symbols.h -DNOT_IN_libc=1 -o /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/rt/tst-timer2.o -MD -MP -MF /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/rt/tst-timer2.o.dt -MT /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/rt/tst-timer2.o + -tst-timer2.c: In function ‘do_test’: + -tst-timer2.c:33: error: ‘SIGRTMIN’ undeclared (first use in this function) + -tst-timer2.c:33: error: (Each undeclared identifier is reported only once + -tst-timer2.c:33: error: for each function it appears in.) + -make[2]: *** [/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/rt/tst-timer2.o] Error 1 + +/usr/bin/install -c -m 644 ../include/pthread.h /usr/include/pthread.h + +/usr/bin/install: cannot remove `/usr/include/pthread.h': Permission denied + +make[2]: *** [/usr/include/pthread.h] Error 1 + + -i486-gnu-gcc tst-thrlock.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -g -Wno-parentheses -Wstrict-prototypes -mpreferred-stack-boundary=2 -I../include -I/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/elf -I/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build -I../sysdeps/i386/elf -I../sysdeps/mach/hurd/i386 -I../sysdeps/mach/hurd -I../sysdeps/gnu -I../sysdeps/unix/bsd/bsd4.4 -I../sysdeps/unix/mman -I../sysdeps/mach/i386 -I../sysdeps/mach -I../sysdeps/i386/i486 -I../sysdeps/i386/fpu -I../sysdeps/i386 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/unix/bsd -I../sysdeps/unix/common -I../sysdeps/unix/inet -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -I../hurd -I/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/hurd/ -I../mach -I/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/mach/ -I.. -I../libio -I. -D_LIBC_REENTRANT -include ../include/libc-symbols.h -DNOT_IN_libc=1 -o /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/elf/tst-thrlock.o -MD -MP -MF /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/elf/tst-thrlock.o.dt -MT /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/elf/tst-thrlock.o + -i486-gnu-gcc -nostdlib -nostartfiles -o /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/elf/tst-thrlock -Wl,-dynamic-linker=/usr/lib/ld.so.1 -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/csu/crt1.o /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/csu/crti.o `i486-gnu-gcc --print-file-name=crtbegin.o` /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/elf/tst-thrlock.o /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/dlfcn/libdl.so.2 -Wl,-rpath-link=/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build:/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/math:/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/elf:/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/dlfcn:/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/nss:/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/nis:/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/rt:/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/resolv:/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/crypt:/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/mach:/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/hurd /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/libc.so.0.3 /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/libc_nonshared.a -lgcc -Wl,--as-needed -lgcc_s -Wl,--no-as-needed `i486-gnu-gcc --print-file-name=crtend.o` /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/csu/crtn.o + -/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/elf/tst-thrlock.o: In function `do_test': + -/media/data/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker/elf/tst-thrlock.c:38: undefined reference to `pthread_create' + -/media/data/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker/elf/tst-thrlock.c:48: undefined reference to `pthread_join' + -collect2: ld returned 1 exit status + -make[2]: *** [/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/elf/tst-thrlock] Error 1 + +/usr/bin/install -c -m 644 ../include/pthread.h /usr/include/pthread.h + +/usr/bin/install: cannot remove `/usr/include/pthread.h': Permission denied + +make[2]: *** [/usr/include/pthread.h] Error 1 diff --git a/open_issues/glibc/debian.mdwn b/open_issues/glibc/debian.mdwn new file mode 100644 index 00000000..ce6ba9d2 --- /dev/null +++ b/open_issues/glibc/debian.mdwn @@ -0,0 +1,46 @@ +[[!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]]."]]"""]] + + +# Open Issues + +`threads = yes` is set in `debian/sysdeps/linux.mk` and +`debian/sysdeps/kfreebsd.mk`, `debian/sysdeps/hurd.mk` set to `no`. But this +is only read in `debian/rules` for deciding some `nscd` package issue? + +`debian/sysdeps/hurd.mk`'s `libc_extra_install` for `ld.so`: check with GCC +configuration. + +Could add a toggle to `$(stamp)build_%` in `debian/rules.d/build.mk` to skip +locale stuff. + +`--disable-compatible-utmp`? + + +# Building + +Run `debian/rules patch` to apply patches (instead of having it done during the +build). Then you can edit files manually. + +Several passes: `libc`, `i686`, `xen`; `EGLIBC_PASSES='libc i686'`, etc. + +If building with `EGLIBC_PASSES=libc` (more specifically, without `xen`), the +`libc0.3-dev_extra_pkg_install` rule in `debian/sysdeps/hurd-i386.mk` will +fail. (Same for `libc6-dev_extra_pkg_install` in `debian/sysdeps/i386.mk`, for +example.) Why is this special handling only done for `xen`, but not for +`i686`? + +Do `export LC_ALL=C` before building, otherwise the testsuite/make error +messages will be different from those stored in the +`debian/testsuite-checking/expected-results-*` files. + +Run `debian/rules build-arch DEB_BUILD_OPTIONS=parallel=2 [EGLIBC_PASSES=...]`. +Can stop with `C-c` during locale stuff or testsuite if only interested in the +build tree. diff --git a/open_issues/glibc_testsuite.mdwn b/open_issues/glibc_testsuite.mdwn deleted file mode 100644 index 4cceb241..00000000 --- a/open_issues/glibc_testsuite.mdwn +++ /dev/null @@ -1,105 +0,0 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled [[GNU Free Documentation -License|/fdl]]."]]"""]] - -[[!tag open_issue_glibc]] - -`configure --without-cvs --prefix= --disable-profile --build=i486-gnu ---host=i486-gnu` - -`make -k check` changes from 538603af899057a9ef9583cc447804ec602a45e5 to -c9fd33ef070def49c078c94f8d9bc9f8a8e267f7. - -Configured with `--prefix=/usr` instead of `--prefix=`. - -Resolved failures: - - * localedata/tst_mblen.out - * localedata/tst_mbrlen.out - * localedata/tst_mbrtowc.out - * localedata/tst_mbsrtowcs.out - * localedata/tst_mbstowcs.out - * localedata/tst_mbtowc.out - * localedata/tst_swscanf.out - * localedata/tst_wcrtomb.out - * localedata/tst_wcsrtombs.out - * localedata/tst_wcstombs.out - * localedata/tst_wctob.out - * localedata/tst_wctomb.out - * localedata/bug-iconv-trans.out - * localedata/tst-wctype.out - * math/test-float.out - * math/test-double.out - * posix/tst-vfork3-mem - * io/tst-mkdirat.out - -New: - - * A lot of `error while loading shared libraries: libmachuser.so.1: cannot - open shared object file: No such file or directory`. Is it perhaps picking - that library up from `$prefix/lib/`? - - New failures; likely due to that: - - * iconvdata/iconv-test.out - * iconvdata/tst-tables.out - * malloc/tst-mtrace.out - * grp/tst_fgetgrent.out - * posix/globtest.out - * posix/wordexp-tst.out - * io/ftwtest.out - * elf/tst-pathopt.out - - Changed failures; likely due to that: - - * debug/tst-chk4.out / debug/tst-chk5.out - - -error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory - +error while loading shared libraries: libpthread-stubs.so.0: cannot open shared object file: No such file or directory - ---- - -Changes to b367d4f996512af6841c3cefdb943cb0a826a6a1: nothing interesting. - ---- - -Changes to b85c54a1f7e5241c1ef99dfeaecbd1bf4117564f: nothing interesting. - -New failures: - - * posix/bug-glob3.out (SEGFAULT; but also on Linux) - * wctype/bug-wctypeh.o (compile error; but also on Linux) - -Other things noticed: - - * Running `make -k check` for the second time: - - -i486-gnu-gcc tst-timer2.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -g -Wno-parentheses -Wstrict-prototypes -mpreferred-stack-boundary=2 -I../include -I/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/rt -I/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build -I../sysdeps/i386/elf -I../sysdeps/mach/hurd/i386 -I../sysdeps/mach/hurd -I../sysdeps/gnu -I../sysdeps/unix/bsd/bsd4.4 -I../sysdeps/unix/mman -I../sysdeps/mach/i386 -I../sysdeps/mach -I../sysdeps/i386/i486 -I../sysdeps/i386/fpu -I../sysdeps/i386 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/unix/bsd -I../sysdeps/unix/common -I../sysdeps/unix/inet -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -I../hurd -I/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/hurd/ -I../mach -I/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/mach/ -I.. -I../libio -I. -D_LIBC_REENTRANT -include ../include/libc-symbols.h -DNOT_IN_libc=1 -o /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/rt/tst-timer2.o -MD -MP -MF /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/rt/tst-timer2.o.dt -MT /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/rt/tst-timer2.o - -tst-timer2.c: In function ‘do_test’: - -tst-timer2.c:33: error: ‘SIGRTMIN’ undeclared (first use in this function) - -tst-timer2.c:33: error: (Each undeclared identifier is reported only once - -tst-timer2.c:33: error: for each function it appears in.) - -make[2]: *** [/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/rt/tst-timer2.o] Error 1 - +/usr/bin/install -c -m 644 ../include/pthread.h /usr/include/pthread.h - +/usr/bin/install: cannot remove `/usr/include/pthread.h': Permission denied - +make[2]: *** [/usr/include/pthread.h] Error 1 - - -i486-gnu-gcc tst-thrlock.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -g -Wno-parentheses -Wstrict-prototypes -mpreferred-stack-boundary=2 -I../include -I/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/elf -I/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build -I../sysdeps/i386/elf -I../sysdeps/mach/hurd/i386 -I../sysdeps/mach/hurd -I../sysdeps/gnu -I../sysdeps/unix/bsd/bsd4.4 -I../sysdeps/unix/mman -I../sysdeps/mach/i386 -I../sysdeps/mach -I../sysdeps/i386/i486 -I../sysdeps/i386/fpu -I../sysdeps/i386 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/unix/bsd -I../sysdeps/unix/common -I../sysdeps/unix/inet -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -I../hurd -I/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/hurd/ -I../mach -I/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/mach/ -I.. -I../libio -I. -D_LIBC_REENTRANT -include ../include/libc-symbols.h -DNOT_IN_libc=1 -o /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/elf/tst-thrlock.o -MD -MP -MF /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/elf/tst-thrlock.o.dt -MT /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/elf/tst-thrlock.o - -i486-gnu-gcc -nostdlib -nostartfiles -o /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/elf/tst-thrlock -Wl,-dynamic-linker=/usr/lib/ld.so.1 -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/csu/crt1.o /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/csu/crti.o `i486-gnu-gcc --print-file-name=crtbegin.o` /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/elf/tst-thrlock.o /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/dlfcn/libdl.so.2 -Wl,-rpath-link=/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build:/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/math:/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/elf:/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/dlfcn:/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/nss:/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/nis:/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/rt:/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/resolv:/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/crypt:/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/mach:/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/hurd /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/libc.so.0.3 /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/libc_nonshared.a -lgcc -Wl,--as-needed -lgcc_s -Wl,--no-as-needed `i486-gnu-gcc --print-file-name=crtend.o` /home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/csu/crtn.o - -/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/elf/tst-thrlock.o: In function `do_test': - -/media/data/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker/elf/tst-thrlock.c:38: undefined reference to `pthread_create' - -/media/data/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker/elf/tst-thrlock.c:48: undefined reference to `pthread_join' - -collect2: ld returned 1 exit status - -make[2]: *** [/home/tschwinge/tmp/glibc/tschwinge--Roger_Whittaker.build/elf/tst-thrlock] Error 1 - +/usr/bin/install -c -m 644 ../include/pthread.h /usr/include/pthread.h - +/usr/bin/install: cannot remove `/usr/include/pthread.h': Permission denied - +make[2]: *** [/usr/include/pthread.h] Error 1 - - * Not all tests are re-run in a `make -k tests; make tests-clean; make -k - tests` cycle. diff --git a/open_issues/unit_testing.mdwn b/open_issues/unit_testing.mdwn index 0def95fa..dd1e465c 100644 --- a/open_issues/unit_testing.mdwn +++ b/open_issues/unit_testing.mdwn @@ -29,8 +29,8 @@ abandoned). * used by the [[GCC testsuite|gcc]], [[GDB testsuite|gdb]], [[binutils testsuite|binutils]], etc. - * The [[glibc_testsuite]] has a home-grown system (Makefile-based), likewise - does the [[Open_POSIX_Test_Suite]]. + * The [[glibc testsuite|glibc]] has a home-grown system (Makefile-based), + likewise does the [[Open_POSIX_Test_Suite]]. * [Kyua](http://code.google.com/p/kyua/) (and its predecessor [ATF](http://www.NetBSD.org/~jmmv/atf/)). -- cgit v1.3.1 From fd416997c65cb122acc1e6c2b36ff10e781273c7 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Fri, 23 Sep 2011 00:44:39 +0200 Subject: open_issues/glibc: Update. --- hurd/translator/procfs/jkoenig/discussion.mdwn | 6 ++ open_issues/glibc.mdwn | 127 +++++++++++++++++-------- 2 files changed, 91 insertions(+), 42 deletions(-) (limited to 'hurd') diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn index 01bbea42..135b4a88 100644 --- a/hurd/translator/procfs/jkoenig/discussion.mdwn +++ b/hurd/translator/procfs/jkoenig/discussion.mdwn @@ -207,3 +207,9 @@ IRC, freenode, #hurd, 2011-07-25 < pinotree> and the mnt C api already returns no entries (or it bails out, i don't remember) < pinotree> not a strict need + + +# `/proc/[PID]/auxv`, `/proc/[PID]/exe`, `/proc/[PID]/mem` + +Needed by glibc's `pldd` tool (commit +11988f8f9656042c3dfd9002ac85dff33173b9bd). diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn index e7c8a0ba..0130aceb 100644 --- a/open_issues/glibc.mdwn +++ b/open_issues/glibc.mdwn @@ -27,8 +27,8 @@ Here's what's to be done for maintaining glibc. # Configuration -Last reviewed up to the [[Git mirror's 5a31b2836d55bcc0c5b6f90f1e89245118e7f508 -(2011-06-07) sources|source_repositories/glibc]]. +Last reviewed up to the [[Git mirror's 16292eddd77f66002e2104848e75a0fb4d316692 +(2011-08-04) sources|source_repositories/glibc]]. * t/dup3 @@ -51,6 +51,14 @@ Last reviewed up to the [[Git mirror's 5a31b2836d55bcc0c5b6f90f1e89245118e7f508 * `TLS_INIT_TP_EXPENSIVE` is unused; Hurd def. can be removed. + * t/verify.h + + People didn't like this too much. + + Other examples: + + * 11988f8f9656042c3dfd9002ac85dff33173b9bd -- `static_assert` + * [[toolchain/cross-gnu]], without `--disable-multi-arch` i686-pc-gnu-gcc ../sysdeps/i386/i686/multiarch/strcmp.S -c [...] @@ -134,10 +142,12 @@ Last reviewed up to the [[Git mirror's 5a31b2836d55bcc0c5b6f90f1e89245118e7f508 something to work on, here's a list. `AT_EMPTY_PATH`, `CLOCK_BOOTTIME`, `CLOCK_BOOTTIME_ALARM`, - `CLOCK_REALTIME_ALARM`, `O_PATH`, `RLIMIT_RTTIME`, `clock_adjtime`, - `fallocate`, `fallocate64`, `getcontext` (and `setcontext`), - `name_to_handle_at`, `open_by_handle_at`, `sendmmsg`, `setns`, - `sync_file_range` + `CLOCK_REALTIME_ALARM`, `O_PATH`, + `PTRACE_*` (for example, cbff0d9689c4d68578b6a4f0a17807232506ea27), + `RLIMIT_RTTIME`, `SEEK_DATA` (`unistd.h`), `SEEK_HOLE` (`unistd.h`) + `clock_adjtime`, `fallocate`, `fallocate64`, `getcontext` (and + `setcontext`), `name_to_handle_at`, `open_by_handle_at`, `sendmmsg`, + `setns`, `sync_file_range` * `syncfs` @@ -153,12 +163,38 @@ Last reviewed up to the [[Git mirror's 5a31b2836d55bcc0c5b6f90f1e89245118e7f508 Do we support `AT_FDCWD` et al.? + * `MAP_POPULATE` (`mmap`, `sys/mman.h`) + + Is only advisory, so can worked around with `#define 0`. + * Building with GCC 4.5, 4.6, trunk will cause different kinds of faults. * Create `t/cleanup_kernel-features.h`. * Add tests from Linux kernel commit messages for `t/dup3` et al. + * In `sysdeps/unix/sysv/linux/Makefile`, there are a bunch of + `-DHAVE_SENDFILE` -- but we do have `sendfile`, too. + + * `/usr/include/pthread.h` overwrite issue + + `make`, after editing `nss/nss_db/db-initgroups.c`: + + [...] + make[2]: Leaving directory `/media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker/resolv' + make subdir=nss -C nss ..=../ others + make[2]: Entering directory `/media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker/nss' + /usr/bin/install -c -m 644 ../include/pthread.h /usr/include/pthread.h + /usr/bin/install: cannot remove `/usr/include/pthread.h': Permission denied + make[2]: *** [/usr/include/pthread.h] Error 1 + make[2]: Leaving directory `/media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker/nss' + make[1]: *** [nss/others] Error 2 + make[1]: Leaving directory `/media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker' + make: *** [all] Error 2 + + See `id:"871uv99c59.fsf@kepler.schwinge.homeip.net"`. Passing + `install_root=/INVALID` to `make`/`make check` is a cheap cure. + * Verify baseline changes, if we need any follow-up changes: * a11ec63713ea3903c482dc907a108be404191a02 @@ -249,26 +285,58 @@ Last reviewed up to the [[Git mirror's 5a31b2836d55bcc0c5b6f90f1e89245118e7f508 80e2212d8e59933a1641f029ebd360526ff0e074 + 4997db742946d08be4378cf91221f558f928bc73 -- `Don't document si_code used for raise()`. Also for `bits/siginfo.h`? - * 01f16ab0a581838d44ad79e82c0c3e1691d8506e -- `Prevent loader from - loading itself` + * 11988f8f9656042c3dfd9002ac85dff33173b9bd -- pldd, Does it work? + Probably not: needs `/proc/[PID]/auxv`, `/proc/[PID]/exe`, + `/proc/[PID]/mem` ([[!tag open_issue_hurd]], + [[hurd/translator/procfs]]). + * 78a7eee7fab0802addf500c481335ed6e9899bda + + 62bede1313c3a1fa477a092006d64436de6821b1 + + 113ddea44742d006d7a910a0707106c7defcfd9b -- `.ctors/.dtors`. Watch + what happens. `AC_TRY_LINK` vs. cross compiling/bootstrapping? Native + build: `checking whether to use .ctors/.dtors header and + trailer... no`; results in `#define NO_CTORS_DTORS_SECTIONS 1`: OK (as + before). + * 9113ea1f3f29b3aee710efc829e85a9772bcb836 -- `--experimental-malloc`. + Watch what happens. + * 4e34ac6a1e256f40ab0d8eeed37aa1ea83440e76 -- `-defsym=_begin=0`. Watch + what happens. Native build: apparently OK. + * f781ef4015504e8a1da649c266584976238aa079 (`--with-default-link`) + + 1b74661a6b93a892ecb1c717dedeedba5c2a976c + + fd5e21c75d8e9221d766f4bc922a237265514ec2. Watch what happens. Native + build: `use-default-link = no`. + * de283087c74f720cf8a7171972e72b5fa2b45e79 (`Handle Lustre filesystem`), + 4e5f31c847982997c856f03bbc35134e9fd0f61f (`Handle ext4 in + {,f}pathconf`). What about stuff like that for us? + * d30cf5bb00bfb286ff14d931fb69f5b53724bcdc (`Find readelf with + AC_CHECK_TOOL`). Aren't there more in other configure.in and Makefile + files? + * 574920b446870648623a85e00dd8f3ca9f482c0e (`Rewrite -z relro configure + check`) + defe906180bad4e356bb55b60b10abd41b7ee3a1 + + 9fa2c03227e159050e9dc4ec1e315e5909901580. Watch what happens. Native + build: OK, `yes` (as before). + * 5c55070081c27168d27145afdf6a92cd56c9abb3 (`linker + --print-output-format`). Watch what happens. Native build: OK, + `elf32-i386`. + * 7a03a9c8c4b37b88ac5e82b557d974f3161ddaf9 (`Add read barriers in + cancellation initialization`). Is this needed in other places, too? # Build Here's a log of a glibc build run; this is from our [[Git repository's -d97df6798c8f0fd8e21c2610a1cfac2e3272b5f1 (2011-09-19; 2011-06-07) +946cceff76422cedd8ca2f50bced0a672e64a9a9 (2011-09-22; 2011-08-04) sources|source_repositories/glibc]], run on coulomb.SCHWINGE. $ export LC_ALL=C - $ ../Roger_Whittaker/configure --without-cvs --prefix=/usr --disable-profile --disable-multi-arch --build=i486-gnu --host=i486-gnu CC=gcc-4.4 CXX=g++-4.4 2>&1 | tee log_build + $ ../Roger_Whittaker/configure AUTOCONF=: --without-cvs --prefix=/usr --disable-profile --disable-multi-arch --build=i486-gnu --host=i486-gnu CC=gcc-4.4 CXX=g++-4.4 2>&1 | tee log_build [...] - $ make 2>&1 | tee log_build_ + $ make install_root=/INVALID 2>&1 | tee log_build_ [...] This takes up around 400 MiB and needs roughly 120 min on coulomb.SCHWINGE.