From 5873c9b664528a5fe35bf3ea22abe785ace6f86a Mon Sep 17 00:00:00 2001 From: Arne Babenhauserheide Date: Tue, 19 Jul 2011 10:12:45 +0200 Subject: typo --- hurd/documentation/translator_primer.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'hurd') diff --git a/hurd/documentation/translator_primer.mdwn b/hurd/documentation/translator_primer.mdwn index 24e66681..4586a8e6 100644 --- a/hurd/documentation/translator_primer.mdwn +++ b/hurd/documentation/translator_primer.mdwn @@ -29,7 +29,7 @@ To try out the simplest of translators, you can go the following simple steps: $ touch hello $ cat hello - $ setrans hello /hurd/hello + $ settrans hello /hurd/hello $ cat hello "Hello World!" $ settrans -g hello -- cgit v1.2.3 From 786cc5604dbad7eeb8ee2dbabdd38e008d838720 Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Tue, 19 Jul 2011 20:05:00 +0200 Subject: comment on _POSIX_PATH_MAX and realpath bogusness --- 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 ade921b0..fc3f518f 100644 --- a/hurd/porting/guidelines.mdwn +++ b/hurd/porting/guidelines.mdwn @@ -54,6 +54,10 @@ If you get Bad File Descriptor error when trying to read from a file (or accessi 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. + +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. + ## `ARG_MAX` Same rationale as `PATH_MAX`. There is no limit on the number of arguments. -- cgit v1.2.3 From 33b91f458ed0f728933f2d5aa5ec2ae1a86a9d4d Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 20 Jul 2011 13:35:48 +0200 Subject: Misc bits from emails by Samuel and Jérémie. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- glibc.mdwn | 5 +++++ glibc/signal.mdwn | 5 ++++- glibc/signal/signal_thread.mdwn | 7 +++++++ hurd/running/qemu.mdwn | 5 +++++ 4 files changed, 21 insertions(+), 1 deletion(-) (limited to 'hurd') diff --git a/glibc.mdwn b/glibc.mdwn index 6c49508f..c7313c1c 100644 --- a/glibc.mdwn +++ b/glibc.mdwn @@ -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]] bugs around signals are very tricky 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. -- cgit v1.2.3 From 58e262611fe8cae64db2e7989280d4e23e9d806d Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 20 Jul 2011 14:04:41 +0200 Subject: hurd/porting/guidelines: Formatting. --- hurd/porting/guidelines.mdwn | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) (limited to 'hurd') 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. -## `PATH_MAX` / `MAX_PATH` / `MAXPATHLEN` +## `PATH_MAX`, `MAX_PATH`, `MAXPATHLEN`, `_POSIX_PATH_MAX` 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. ## `ARG_MAX` -- cgit v1.2.3