diff options
| -rw-r--r-- | glibc.mdwn | 5 | ||||
| -rw-r--r-- | glibc/signal.mdwn | 5 | ||||
| -rw-r--r-- | glibc/signal/signal_thread.mdwn | 7 | ||||
| -rw-r--r-- | hurd/porting/guidelines.mdwn | 15 | ||||
| -rw-r--r-- | hurd/running/qemu.mdwn | 5 | ||||
| -rw-r--r-- | open_issues/gnumach_vm_map_entry_forward_merging.mdwn | 68 | ||||
| -rw-r--r-- | user/jkoenig/java.mdwn | 8 | ||||
| -rw-r--r-- | user/jkoenig/java/discussion.mdwn | 33 |
8 files changed, 140 insertions, 6 deletions
@@ -28,6 +28,11 @@ Porting glibc to a specific architecture is non-trivial. ## [[Hurd-specific Port|hurd/glibc]] +An important part of the [[Hurd]] actually resides in glibc: here, the POSIX +interfaces are implemented on top of the [[Hurd IPC protocols|hurd/interface]]. +This is different to the Linux port, where most simple POSIX interfaces are in +fact simply forwarded to/implemented as [[system_call]]s. + # Implementation Details diff --git a/glibc/signal.mdwn b/glibc/signal.mdwn index 84153cff..727247ac 100644 --- a/glibc/signal.mdwn +++ b/glibc/signal.mdwn @@ -10,8 +10,11 @@ is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] The [[*UNIX signalling mechanism*|unix/signal]] is implemented for the GNU Hurd -by means of a separate *[[signal_thread]]* that is part of every +by means of a separate *[[signal_thread]]* that is part of every user-space [[process]]. This makes handling of signals a separate thread of control. +[[GNU Mach|microkernel/mach/gnumach]] itself has no idea what a signal is and +`kill` is not a [[system_call]] (as it typically is in a [[UNIX]] system): it's +implemented in [[glibc]]. * [[SA_SIGINFO, SA_SIGACTION|open_issues/sa_siginfo_sa_sigaction]] diff --git a/glibc/signal/signal_thread.mdwn b/glibc/signal/signal_thread.mdwn index 28855dbd..5341b1ab 100644 --- a/glibc/signal/signal_thread.mdwn +++ b/glibc/signal/signal_thread.mdwn @@ -8,6 +8,13 @@ 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]]."]]"""]] +For delivering a signal, Mach forwards an `msg_sig_post` message from the +invoker of `kill` to the target process. The target process' [[signal_thread]] +job is it to listen to such messages and to set up signal handler contexts in +other threads. + +--- + [[!tag open_issue_documentation]] <braunr> bugs around signals are very tricky diff --git a/hurd/porting/guidelines.mdwn b/hurd/porting/guidelines.mdwn index fc3f518f..8b7dcf02 100644 --- a/hurd/porting/guidelines.mdwn +++ b/hurd/porting/guidelines.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2002, 2003, 2005, 2007, 2008, 2009 Free Software -Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2003, 2005, 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 @@ -50,13 +50,18 @@ An example with `fpathconf`: If you get Bad File Descriptor error when trying to read from a file (or accessing it at all), check the `open()` invocation. The second argument is the access method. If it is a hard coded number instead of a symbol defined in the standard header files, the code is screwed and should be fixed to either use `O_RDONLY`, `O_WRONLY` or `O_RDWR`. This bug was observed in the `fortunes` and `mtools` packages for example. -## <a name="PATH_MAX_tt_MAX_PATH_tt_MAXPATHL"> `PATH_MAX` / `MAX_PATH` / `MAXPATHLEN` </a> +## <a name="PATH_MAX_tt_MAX_PATH_tt_MAXPATHL">`PATH_MAX`, `MAX_PATH`, `MAXPATHLEN`, `_POSIX_PATH_MAX`</a> Every unconditionalized use of `PATH_MAX`, `MAX_PATH` or `MAXPATHLEN` is a POSIX incompatibility. If there is no upper limit on the length of a path (as its the case for GNU), this symbol is not defined in any header file. Instead, you need to either use a different implementation that does not rely on the length of a string or use `sysconf()` to query the length at runtime. If `sysconf()` returns -1, you have to use `realloc()` to allocate the needed memory dynamically. Usually it is thus simpler to just use dynamic allocation. Sometimes the amount is actually known. Else, a geometrically growing loop can be used: for instance, see [Alioth patch](http://alioth.debian.org/tracker/download.php/30628/410472/303735/1575/cpulimit-path-max-fix.patch) or [Pulseaudio patch](http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=patch-pulse;att=1;bug=522100). Note that in some cases there are GNU extensions that just work fine: when the `__GLIBC__` macro is defined, `getcwd()` calls can be just replaced by `get_current_dir_name()` calls. -Note: constants such as _POSIX_PATH_MAX are only the minimum required value for a potential corresponding PATH_MAX macro. They are not a replacement for PATH_MAX, just the minimum value that one can assume. +Note: constants such as `_POSIX_PATH_MAX` are only the minimum required value +for a potential corresponding `PATH_MAX` macro. They are not a replacement for +`PATH_MAX`, just the minimum value that one can assume. -Note2: Yes, some POSIX functions such as realpath() actually assume that PATH_MAX is defined. This is a bug of the POSIX standard, which got fixed in the latest revisions, in which one can simply pass NULL to get a dynamically allocated buffer. +Note 2: Yes, some POSIX functions such as `realpath()` actually assume that +`PATH_MAX` is defined. This is a bug of the POSIX standard, which got fixed in +the latest revisions, in which one can simply pass `NULL` to get a dynamically +allocated buffer. ## <a name="ARG_MAX"> `ARG_MAX` </a> diff --git a/hurd/running/qemu.mdwn b/hurd/running/qemu.mdwn index 9f085d24..343707fa 100644 --- a/hurd/running/qemu.mdwn +++ b/hurd/running/qemu.mdwn @@ -100,6 +100,11 @@ If your machine supports hardware acceleration, you should really use the kvm va to the command line, see below, if you are running Linux kernels 2.6.37 or 2.6.38 else IRQs may hang sooner or later. The kvm irq problems will be solved in kernel 2.6.39. +/!\ Note that there are known performance issues with KVM on Linux 2.6.39 +kernels, compared to 2.6.32: [[!debbug 634149]]. We're preparing on a change +on our side to work around this. + + # 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. diff --git a/open_issues/gnumach_vm_map_entry_forward_merging.mdwn b/open_issues/gnumach_vm_map_entry_forward_merging.mdwn new file mode 100644 index 00000000..58013021 --- /dev/null +++ b/open_issues/gnumach_vm_map_entry_forward_merging.mdwn @@ -0,0 +1,68 @@ +[[!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_gnumach]] + + +# IRC, freenode, #hurd, 2011-07-20 + + <braunr> could we add gnumach forward map entry merging as an open issue ? + <braunr> probably hurting anything using bash extensively, like build most + build systems + <braunr> mcsim: this map entry merging problem might interest you + <braunr> tschwinge: see vm/vm_map.c, line ~905 + <braunr> "See whether we can avoid creating a new entry (and object) by + extending one of our neighbors. [So far, we only attempt to extend from + below.]" + <braunr> and also vm_object_coalesce + <braunr> "NOTE: Only works at the moment if the second object is NULL - + if it's not, which object do we lock first?" + <braunr> although map entry merging should be enough + <braunr> this seems to be the cause for bash having between 400 and 1000+ + map entries + <braunr> thi makes allocations and faults slow, and forks even more + <braunr> but again, this should be checked before attempting anything + <braunr> (for example, this comment still exists in freebsd, although they + solved the problem, so who knows) + <antrik> braunr: what exactly would you want to check? + <antrik> braunr: this rather sounds like something you would just have to + try... + <braunr> antrik: that map merging is actually incomplete + <braunr> and that entries can actually be merged + <antrik> hm, I see... + <braunr> (i.e. they are adjacent and have compatible properties + <braunr> ) + <braunr> antrik: i just want to avoid the "hey, splay trees mak fork slow, + let's work on it for a month to see it wasn't the problem" + <antrik> so basically you need a dump of a task's map to check whether + there are indeed entries that could/should be merged? + <antrik> hehe :-) + <braunr> well, vminfo should give that easily, i just didn't take the time + to check it + <jkoenig> braunr, as you pointed out, "vminfo $$" seems to indicate that + merging _is_ incomplete. + <braunr> this could actually have a noticeable impact on package builds + + +# Procedure + + * Analyze. + + * Measure. + + * Fix. + + * Measure again. + + * Have [[tschwinge]] measure with gcc build (currently needs 11 h). + [[tschwinge]] will in the mean time figure out the difference between using + bash and dash. + + * Have Samuel measure on the buildd. diff --git a/user/jkoenig/java.mdwn b/user/jkoenig/java.mdwn index 700f9c4e..9732e2cd 100644 --- a/user/jkoenig/java.mdwn +++ b/user/jkoenig/java.mdwn @@ -50,6 +50,14 @@ My latest code is available on and modified Debian packages are available in my apt repository. +2011-07-20: +The patches were reviewed by Samuel Thibault. +Samuel pointed out a couple of issues +and I beleive I have addressed all of them (fixes posted). +I'm in the process of publishing updated libc and hurd packages; +provided those work as expected, +the next step would be to get these changes into Debian. + One question is how the new symbols introduced by my patches should be handled. Weak symbols turned out to be impractical, diff --git a/user/jkoenig/java/discussion.mdwn b/user/jkoenig/java/discussion.mdwn index f16d7678..352f6d62 100644 --- a/user/jkoenig/java/discussion.mdwn +++ b/user/jkoenig/java/discussion.mdwn @@ -77,6 +77,39 @@ either new ones or existing ones, as applicable. pages ([[!taglink open_issue_documentation]]). +# Java Native Interface (JNI) + + * <http://en.wikipedia.org/wiki/Java_Native_Interface> + * <http://download.oracle.com/javase/7/docs/technotes/guides/jni/> + * <http://java.sun.com/products/jdk/faq/jnifaq.html> + * <http://java.sun.com/docs/books/jni/> + + +## Java Native Access (JNA) + + * <http://jna.java.net/> + * <https://github.com/twall/jna#readme> + +This is a different approach, and *while some attention is paid to performance, +correctness and ease of use take priority*. + +As we plan on only having a few native methods (for invoking `mach_msg`, +essentially), JNA is probably the wrong approach: portability and ease of use +is not important, but performance is. + +## Compiled Native Interface (CNI) + + * <http://gcc.gnu.org/onlinedocs/gcj/About-CNI.html> + * <http://per.bothner.com/papers/UsenixJVM01/CNI01.pdf> + +Probably faster than JNI, but only usable with GCJ. + +> Given that we have very few JNI calls, +> it might be interesting to take a "dual" approach +> if CNI actually improves performance +> when compiling to native code. +> --[[jkoenig]] 2011-07-20 + # IRC, freenode, #hurd, 2011-07-13 [[!tag open_issue_documentation]] |