diff options
Diffstat (limited to 'hurd')
| -rw-r--r-- | hurd/debugging/glibc.mdwn | 8 | ||||
| -rw-r--r-- | hurd/documentation/translator_primer.mdwn | 6 | ||||
| -rw-r--r-- | hurd/io_path.mdwn | 83 | ||||
| -rw-r--r-- | hurd/porting/guidelines.mdwn | 74 | ||||
| -rw-r--r-- | hurd/porting/system_api_limitations.mdwn | 4 | ||||
| -rw-r--r-- | hurd/running/debian/after_install.mdwn | 33 | ||||
| -rw-r--r-- | hurd/running/debian/dhcp.mdwn | 7 | ||||
| -rw-r--r-- | hurd/running/debian/patch_submission.mdwn | 27 | ||||
| -rw-r--r-- | hurd/running/qemu.mdwn | 7 | ||||
| -rw-r--r-- | hurd/subhurd/discussion.mdwn | 69 | ||||
| -rw-r--r-- | hurd/translator/discussion.mdwn | 25 | ||||
| -rw-r--r-- | hurd/translator/pfinet/dhcp.mdwn | 33 | ||||
| -rw-r--r-- | hurd/translator/procfs/jkoenig/discussion.mdwn | 47 | ||||
| -rw-r--r-- | hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn | 115 |
14 files changed, 455 insertions, 83 deletions
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/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 diff --git a/hurd/io_path.mdwn b/hurd/io_path.mdwn index 0d83a4ba..492edffe 100644 --- a/hurd/io_path.mdwn +++ b/hurd/io_path.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2008, 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 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 @@ -10,21 +11,77 @@ License|/fdl]]."]]"""]] [[!meta title="I/O Path"]] +[[!tag open_issue_documentation]] <!-- Someone still needs to make a pass over +this text. --> -# read +[[!toc]] - * [[glibc]]'s `read` is in `glibc/sysdeps/mach/hurd/read.c:__libc_read`. - * That calls `glibc/hurd/fd-read.c:_hurd_fd_read()`. +# `read`, [[libtrivfs]] - * 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`. +[[glibc]]'s `read` is in `glibc/sysdeps/mach/hurd/read.c:__libc_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. +A buffer (and its size) to store the to-be-read data in is supplied by the +caller of `read`. + +> `__libc_read` calls `glibc/hurd/fd-read.c:_hurd_fd_read`. + +>> `_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 internal 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`. + + +# `read`, [[hurd/translator/ext2fs]]/[[hurd/libdiskfs]] + +(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`, @@ -50,7 +107,3 @@ License|/fdl]]."]]"""]] nice overview of the related layering inside the Linux kernel, including the VFS layer, page cache and directory entry cache (dcache). - - -[[!tag open_issue_documentation]] <!-- Merge kepler.SCHWINGE/master-io_path. ---> diff --git a/hurd/porting/guidelines.mdwn b/hurd/porting/guidelines.mdwn index 8b7dcf02..efc8982a 100644 --- a/hurd/porting/guidelines.mdwn +++ b/hurd/porting/guidelines.mdwn @@ -22,6 +22,66 @@ 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. +## <a name="GNU build system"> GNU build system </a> + +For a good overview of the components in the GNU build system, see +<http://en.wikipedia.org/wiki/GNU_build_system> and +<http://www.gnu.org/s/hello/manual/autoconf/index.html>. + +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'. 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 +'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. + +## <a name="autoconf"> Fixing configure.{ac,in} </a> + +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*) + +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... + +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. ## <a name="Undefined_bits_confname_h_tt_mac"> Undefined `bits/confname.h` macros (`PIPE_BUF`, ...) </a> @@ -192,7 +252,11 @@ then be found. ## <a name="SA_SIGINFO"> `SA_SIGINFO` </a> -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. + +## <a name="SA_NOCLDWAIT"> `SA_NOCLDWAIT` </a> + +Not implemented yet. ## <a name="SOL_IP"> `SOL_IP` </a> @@ -279,9 +343,13 @@ With Python, you can use the [`errno` module](http://docs.python.org/library/err err.errno == errno.ENOENT: ... -## <a name="linux_headers"> Missing `linux/types.h`, `asm/types.h`, `linux/limits.h`, `asm/byteorder.h`, `sys/endian.h`, `asm/ioctl.h`, `asm/ioctls.h` </a> +## <a name="libdl"> undefined reference to `dlopen`, `dlsym`, `dlclose` </a> + +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` + +## <a name="linux_headers"> 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` </a> -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` ## <a name="linux_features"> Missing `sys/*.h`, `linux/*.h`</a> diff --git a/hurd/porting/system_api_limitations.mdwn b/hurd/porting/system_api_limitations.mdwn index 2fac456e..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 @@ -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 `<sys/shm.h>`)_**<br />**breaks:** cdrtools<br />**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++_**<br />**breaks:** fam, gail<br />**status:** maybe this should be in [[PortingIssues]] (see _long_ bug log) 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]]. 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 66348dd9..1dd8a4db 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. @@ -27,14 +28,24 @@ either use the reportbug tool, or just simple mail. In any case, you should follow these guidelines: * The submission address is <submit@bugs.debian.org>. + * 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` + + 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 + +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 diff --git a/hurd/running/qemu.mdwn b/hurd/running/qemu.mdwn index 343707fa..b2812750 100644 --- a/hurd/running/qemu.mdwn +++ b/hurd/running/qemu.mdwn @@ -105,6 +105,13 @@ kernels, compared to 2.6.32: [[!debbug 634149]]. We're preparing on a change on our side to work around this. +# HAP/EPT/NPT acceleration + +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 Note: If you have hardware support, replace the qemu commands below with kvm, e.g. qemu-ing -> kvm-img. 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/pfinet/dhcp.mdwn b/hurd/translator/pfinet/dhcp.mdwn index 17776fa5..456d0c84 100644 --- a/hurd/translator/pfinet/dhcp.mdwn +++ b/hurd/translator/pfinet/dhcp.mdwn @@ -1,27 +1,33 @@ +[[!meta copyright="Copyright © 2002, 2003, 2005, 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]] +[[Debian GNU/Hurd|running/debian]] has some script hackery to get +[[running/debian/DHCP]] going. + +--- + 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. [Link to thread](http://lists.gnu.org/archive/html/bug-hurd/2005-01/msg00025.html) 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). --- [[Main/ThadeuCascardo]] - 29 Sep 2005 - -No DHCP client has been ported to the Hurd yet. - [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. @@ -38,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/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn index b66af7de..135b4a88 100644 --- a/hurd/translator/procfs/jkoenig/discussion.mdwn +++ b/hurd/translator/procfs/jkoenig/discussion.mdwn @@ -166,3 +166,50 @@ IRC, freenode, #hurd, 2011-03-28 mentoring the previous procfs implementation <antrik> (though I never got around to look at his buggy code...) <jkoenig> ok + +IRC, freenode, #hurd, 2011-07-22 + + <pinotree> hm, why /proc/$pid/stat is 600 instead of 644 of linux? + <jkoenig> pinotree, it reveals information which, while not that sensitive, + would not be available to users through the normal proc interface. + <jkoenig> (it's available through the ps command which is setuid root) + <jkoenig> we discussed at some point making it 644, IIRC. + <pinotree> hm, then why is it not a problem on eg linux? + <jkoenig> (btw you can change it with the -s option.) + <jkoenig> 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. + <jkoenig> IIRC it's not sensitive but you need the task port to query it. + <jkoenig> like, thread times or something. + <pinotree> status is 644 though + <jkoenig> 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 + + +# `/proc/[PID]/auxv`, `/proc/[PID]/exe`, `/proc/[PID]/mem` + +Needed by glibc's `pldd` tool (commit +11988f8f9656042c3dfd9002ac85dff33173b9bd). diff --git a/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn b/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn index f0eb473c..ecebe662 100644 --- a/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn +++ b/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn @@ -8,9 +8,10 @@ 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_gnumach open_issue_hurd]] -\#hurd, freenode, 2010 + +# IRC, freenode, #hurd, 2010 <slpz> humm... why does tmpfs try to use the default pager? that's a bad idea, and probably will never work correctly... @@ -120,3 +121,113 @@ License|/fdl]]."]]"""]] memory, gives them a reference to the default pager by calling vm_object_pager_create <slpz> this is not really important, but worth noting ;-) + + +# IRC, freenode, #hurd, 2011-09-28 + + <slpz> mcsim: "Fix tmpfs" task should be called "Fix default pager" :-) + <slpz> mcsim: I've been thinking about modifying tmpfs to actually have + it's own storeio based backend, even if a tmpfs with storage sounds a bit + stupid. + <slpz> mcsim: but I don't like the idea of having translators messing up + with the default pager... + <antrik> slpz: messing up?... + <slpz> antrik: in the sense of creating a number of arbitrarily sized + objects + <antrik> slpz: well, it doesn't really matter much whether a process + indirectly eats up arbitrary amounts of swap through tmpfs, or directly + through vm_allocate()... + <antrik> though admittedly it's harder to implement resource limits with + tmpfs + <slpz> antrik: but I've talked about having its own storeio device as + backend. This way Mach can pageout memory to tmpfs if it's needed. + <mcsim> Do I understand correctly that the goal of tmpfs task is to create + tmpfs in RAM? + <slpz> mcsim: It is. But it also needs some kind of backend, just in case + it's ordered to page out data to free some system's memory. + <slpz> mcsim: Nowadays, this backend is another translator that acts as + default pager for the whole system + <antrik> slpz: pageout memory to tmpfs? not sure what you mean + <slpz> antrik: I mean tmpfs acting as its own pager + <antrik> slpz: you mean tmpfs not using the swap partition, but some other + backing store? + <slpz> antrik: Yes. + +See also: [[open_issues/resource_management_problems/pagers]]. + + <antrik> slpz: I don't think an extra backing store for tmpfs is a good + idea. the whole point of tmpfs is not having a backing store... TBH, I'd + even like to see a single backing store for anonymous memory and named + files + <slpz> antrik: But you need a backing store, even if it's the default pager + :-) + <slpz> antrik: The question is, Should users share the same backing store + (swap space) or provide their own? + <antrik> slpz: not sure what you mean by "users" in this context :-) + <slpz> antrik: Real users with the ability of setting tmpfs translators + <antrik> essentially, I'd like to have a single partition that contains + both swap space and the main filesystem (at least /tmp, but probably also + all of /run, and possibly even /home...) + <antrik> but that's a bit off-topic :-) + <antrik> well, ideally all storage should be accounted to a user, + regardless whether it's swapped out anonymous storage, temporary named + files, or permanent files + <slpz> antrik: you could use a file as backend for tmpfs + <antrik> slpz: what's the point of using tmpfs then? :-) + <pinotree> (and then store the file in another tmpfs) + <slpz> antrik: mach-defpager could be modified to use storeio instead of + Mach's device_* operations, but by the way things work right now, that + could be dangerous, IMHO + <antrik> pinotree: hehe + <pinotree> .. recursive tmpfs'es ;) + <antrik> slpz: hm, sounds interesting + <slpz> antrik: tmpfs would try to keep data in memory always it's possible + (not calling m_o_lock_request would do the trick), but if memory is + scarce an Mach starts paging out, it would write it to that + file/device/whatever + <antrik> ideally, all storage used by system tasks for swapped out + anonymous memory as well as temporary named files would end up on the + /run partition; while all storage used by users would end up in /home/* + <antrik> if users share a partition, some explicit storage accounting would + be useful too... + <antrik> slpz: is that any different from what "normal" filesystems do?... + <antrik> (and *should* it be different?...) + <slpz> antrik: Yes, as most FS try to synchronize to disk at a reasonable + rate, to prevent data losses. + <slpz> antrik: tmpfs would be a FS that wouldn't synchronize until it's + forced to do that (which, by the way, it's what's currently happening + with everyone that uses the default pager). + <antrik> slpz: hm, good point... + <slpz> antrik: Also, metadata in never written to disk, only kept in memory + (which saves a lot of I/O, too). + <slpz> antrik: In fact, we would be doing the same as every other kernel + does, but doing it explicitly :-) + <antrik> I see the use in separating precious data (in permanent named + files) from temporary state (anonymous memory and temporary named files) + -- but I'm not sure whether having a completely separate FS for the + temporary data is the right approach for that... + <slpz> antrik: And giving the user the option to specify its own storage, + so we don't limit him to the size established for swap by the super-user. + <antrik> either way, that would be a rather radical change... still would + be good to fix tmpfs as it is first if possible + <antrik> as for limited swap, that's precisely why I'd prefer not to have + an extra swap partition at all... + <slpz> antrik: It's not much o fa change, it's how it works right now, with + the exception of replacing the default pager with its own. + <slpz> antrik: I think it's just a matter of 10-20 hours, as + much. Including testing. + <slpz> antrik: It could be forked with another name, though :-) + <antrik> slpz: I don't mean radical change in the implementation... but a + radical change in the way it would be used + <slpz> antrik: I suggest "almosttmpfs" as the name for the forked one :-P + <antrik> hehe + <antrik> how about lazyfs? + <slpz> antrik: That sound good to me, but probably we should use a more + descriptive name :-) + + +## 2011-09-29 + + <tschwinge> slpz, antrik: There is a defpager in the Hurd code. It is not + currently being used, and likely incomplete. It is backed by libstore. + I have never looked at it. |