diff options
Diffstat (limited to 'hurd')
| -rw-r--r-- | hurd/debugging/translator/capturing_stdout_and_stderr.mdwn | 9 | ||||
| -rw-r--r-- | hurd/porting/guidelines.mdwn | 15 | ||||
| -rw-r--r-- | hurd/running/debian/porting.mdwn | 2 | ||||
| -rw-r--r-- | hurd/running/qemu.mdwn | 4 | ||||
| -rw-r--r-- | hurd/status.mdwn | 81 |
5 files changed, 60 insertions, 51 deletions
diff --git a/hurd/debugging/translator/capturing_stdout_and_stderr.mdwn b/hurd/debugging/translator/capturing_stdout_and_stderr.mdwn index 646738b1..1e8c4ef6 100644 --- a/hurd/debugging/translator/capturing_stdout_and_stderr.mdwn +++ b/hurd/debugging/translator/capturing_stdout_and_stderr.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -9,7 +9,8 @@ is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] Sometimes it may already be helpful to capture a translator's `stdout` and -`stderr`, for example like this: +`stderr`, for example in this situation where [[translator/pfinet]] was +silently dying all the time, without any console output: $ sudo settrans -fgap ↩ /servers/socket/2 ↩ @@ -31,3 +32,7 @@ for appropriate `fflush`es on these, or force them to be line buffered again using the appropriate glibc magic (`setvbuf`). Otherwise you'll see text in the output files only if either glibc herself decides to flush (after some KiB of text) the after translator exits. + +It is a [[!taglink open_issue_hurd]] to decide / implement / fix that +(all?) running (passive?) translators' output should show up on the +console / syslog. diff --git a/hurd/porting/guidelines.mdwn b/hurd/porting/guidelines.mdwn index 1beb53a0..5fd66292 100644 --- a/hurd/porting/guidelines.mdwn +++ b/hurd/porting/guidelines.mdwn @@ -170,12 +170,15 @@ This comes from ioctls. Fixing this is easy if the structure members can be exp `#define _IOT_termios /* Hurd ioctl type field. */ \ _IOT (_IOTS (tcflag_t), 4, _IOTS (cc_t), NCCS, _IOTS (speed_t), 2)` -because `struct termios` holds 4 members of type `tcflag_ts`, then `NCCS` -members of type `cc_tsi` and finaly 2 members of type `speed_ts`. - -As you can see, this limits the number of kinds of members to 3, and in -addition to that (see the bitfield described in `ioctls.h`), the third -kind of member is limited to 3 members. +The rationale behind is that on the Hurd ioctl numbers actually encode how the +data should be transferred via RPC: here `struct termios` holds 4 members of +type `tcflag_ts`, then `NCCS` members of type `cc_tsi` and finaly 2 members of +type `speed_ts`, so the RPC mecanism will know how to transfer them. + +As you can see, this limits the number of contiguous kinds of members to 3, and +in addition to that (see the bitfield described in `ioctls.h`), the third kind +of member is limited to 3 members. This is a design limitation, there is no way +to overcome it at the moment. Note: if a field member is a pointer, then the ioctl can't be expressed this way, and that makes sense, since the server you're talking to diff --git a/hurd/running/debian/porting.mdwn b/hurd/running/debian/porting.mdwn index 10ee4c5c..aa044570 100644 --- a/hurd/running/debian/porting.mdwn +++ b/hurd/running/debian/porting.mdwn @@ -17,7 +17,7 @@ Hurd, however, many programs fail to build for various reasons. A [list of build failures including error messages](http://unstable.buildd.net/buildd/hurd-i386_Failed.html) can be found, as well as a [preliminary -analysis](http://lists.debian.org/debian-hurd/2007/07/msg00000.html) of them and [solutions](http://lists.debian.org/debian-hurd/2007/07/msg00001.html). +analysis](http://lists.debian.org/debian-hurd/2007/07/msg00000.html) of them and [solutions](http://lists.debian.org/debian-hurd/2007/07/msg00001.html), and some more details in [[hurd/porting/guidelines]]. It might be a good idea to record your intention to port something either in the list below or in the [Alioth task diff --git a/hurd/running/qemu.mdwn b/hurd/running/qemu.mdwn index a059f3b1..48d87b35 100644 --- a/hurd/running/qemu.mdwn +++ b/hurd/running/qemu.mdwn @@ -71,7 +71,7 @@ Now take the number of sectors for the beginning of the partition and multiply i ## Having QEMU create *virtual FAT disk images* -[Manual](http://fabrice.bellard.free.fr/qemu/qemu-doc.html#SEC24). +[Manual](http://www.nongnu.org/qemu/qemu-doc.html#SEC25). QEMU has a facility to create FAT file systems on-the-fly: @@ -97,7 +97,7 @@ If you just want to access the internet from within QEMU, you can setup pfinet f # settrans -afgp /servers/socket/2 /hurd/pfinet -i eth0 -a 10.0.2.15 -g 10.0.2.2 -m 255.255.255.0 # echo "nameserver 10.0.2.3" > /etc/resolv.conf -(See also <http://fabrice.bellard.free.fr/qemu/qemu-doc.html#SEC30>.) +(See also <http://www.nongnu.org/qemu/qemu-doc.html#SEC32>.) Outgoing internet connections should just work then. diff --git a/hurd/status.mdwn b/hurd/status.mdwn index cc303dcf..3ee8ddcf 100644 --- a/hurd/status.mdwn +++ b/hurd/status.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2001, 2002, 2007, 2008 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2001, 2002, 2007, 2008, 2009 Free Software +Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -60,42 +60,43 @@ already expect delays; to disappoint them in this way as well would be unfortunate. Moreover, it would lessen the possibility that they would want to try the Hurd again in the future. -## Usability status 2009-06-11 -*(This text is taken from two emails posted on the [[bug-hurd mailinglist|mailing_lists]] -by Olaf Buddenhagen)* - -I have been using the Hurd for most of my everyday work for some two -years now. Most of the time it's pretty OK, but occasionally programs -crash, or the screen session dies, or even the whole system. Also, -various programs simply don't work at all, or don't work in certain -situations. - -While I have learned to work around many of these issues, I don't -believe I would be able to use it as my primary system, without having a -GNU/Linux system running in parallel, as a fallback for all the stuff -that doesn't work on the Hurd. - -My everyday work includes reading/writing email and other texts, preparing and giving -presentations, text-mode web browsing, viewing pictures, IRC, reading -PDF documents, programming, and various other random stuff... - -[...] - -One particular problem for desktop use is the fact that while X does -work, it works very poorly -- it's not only slow and jerky all the time, -but also tends to lock up completely. (At least with the local socket -transport... Haven't tried whether forcing TCP works better.) - -Note that while many of the stability problems are simply bugs to fix, -the system will still be very fragile in the absence of these -- a -simple port leak is sufficient to kill it within seconds. This is -something that can't be easily solved. Properly fixing this will require -a sound resource accounting framework, i.e. very fundamental changes to -the system... Though I tend to believe that it could be improved at -least partially, at the expense of flexibility, by enforcing certain -fixed limits on users, processes etc. like other UNIX systems do. - -[...] - -[But] unlike a few years back [...] the system is stable enough under load nowadays [...]. +## Usability Reports + +### Olaf Buddenhagen, 2009-06-09 + +> I have been using the Hurd for most of my everyday work for some two +> years now. Most of the time it's pretty OK, but occasionally programs +> crash, or the screen session dies, or even the whole system. Also, +> various programs simply don't work at all, or don't work in certain +> situations. +> +> While I have learned to work around many of these issues, I don't +> believe I would be able to use it as my primary system, without having a +> GNU/Linux system running in parallel, as a fallback for all the stuff +> that doesn't work on the Hurd. +> +> My everyday work includes reading/writing email and other texts, preparing and giving +> presentations, text-mode web browsing, viewing pictures, IRC, reading +> PDF documents, programming, and various other random stuff... +> +> [...] +> +> One particular problem for desktop use is the fact that while X does +> work, it works very poorly -- it's not only slow and jerky all the time, +> but also tends to lock up completely. (At least with the local socket +> transport... Haven't tried whether forcing TCP works better.) +> +> Note that while many of the stability problems are simply bugs to fix, +> the system will still be very fragile in the absence of these -- a +> simple port leak is sufficient to kill it within seconds. This is +> something that can't be easily solved. Properly fixing this will require +> a sound resource accounting framework, i.e. very fundamental changes to +> the system... Though I tend to believe that it could be improved at +> least partially, at the expense of flexibility, by enforcing certain +> fixed limits on users, processes etc. like other UNIX systems do. +> +> [...] +> +> [But] unlike a few years back [...] the system is stable enough under +> load nowadays [...]. |