diff options
Diffstat (limited to 'hurd')
25 files changed, 504 insertions, 37 deletions
diff --git a/hurd/console/discussion.mdwn b/hurd/console/discussion.mdwn new file mode 100644 index 00000000..f887d826 --- /dev/null +++ b/hurd/console/discussion.mdwn @@ -0,0 +1,42 @@ +[[!meta copyright="Copyright © 2012 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, OFTC, #debian-hurd, 2012-09-24 + + <allesa> hello, I'm trying to get familiar with the Hurd and would like to + change the keyboard layout in use. It seems all the information I can + find (relating to console-driver-xkb) is out of date, with the latest + info relating to it being that this package should not be used anymore… + <allesa> does anyone know how changing keyboard layouts currently works? + <allesa> ah, never mind. I assume it doesn't currently work: + http://www.gnu.org/software/hurd/hurd/console.htmlq + <allesa> *http://www.gnu.org/software/hurd/hurd/console.html + <youpi> it does actually work + <youpi> simply dpkg-reconfigure keyboard-configuration + <youpi> and reboot + <youpi> (see http://www.debian.org/ports/hurd/hurd-install + <youpi> ) + <allesa> mhm, I got that far — but selecting my layout gave me no joy, even + after restart. Seem to be stuck with the layout chosen during + installation (d-i). Just to check I'm using the right version — still on + the installer isos from 15 July? + <allesa> wait… progress is being made — slowly and subtly… + <allesa> Ok, so the XKBLAYOUT is changing as you described, but XKBVARIANT + seems to be ignored. Could this be right? + <youpi> yes, the hurd console only supports keymaps + <youpi> (currently) + <allesa> Ah OK, thanks for your help on this. I imagine this is not + something that just requires simple repetitive work, but some actual + hacking? + <allesa> to fix that is… + <youpi> some hacking yes diff --git a/hurd/debugging/rpctrace.mdwn b/hurd/debugging/rpctrace.mdwn index df6290f7..c506861a 100644 --- a/hurd/debugging/rpctrace.mdwn +++ b/hurd/debugging/rpctrace.mdwn @@ -167,6 +167,14 @@ See `rpctrace --help` about how to use it. Debian-specific, but not ready for upstream either... <youpi> antrik: yes +* IRC, freenode, #hurd, 2012-07-18 + + <braunr> hm, rpctrace on gitk gives an interesting result + <braunr> 152<--153(pid1849)->io_set_all_openmodes_request (267) = 0 + <braunr> rpctrace: + /home/rbraun/hd0s7/hurd/hurd-20120710/./utils/rpctrace.c:1287: + trace_and_forward: Assertion `reply_type == 18' failed. + # See Also diff --git a/hurd/debugging/translator/capturing_stdout_and_stderr.mdwn b/hurd/debugging/translator/capturing_stdout_and_stderr.mdwn index b7cfc3c9..47fbbc48 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, 2009, 2010 Free Software Foundation, +[[!meta copyright="Copyright © 2008, 2009, 2010, 2012 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]]."]]"""]] Sometimes it may already be helpful to capture a translator's `stdout` and `stderr`, for example in this situation where [[translator/pfinet]] was @@ -15,13 +15,14 @@ silently dying all the time, without any console output: $ sudo settrans -fgap ↩ /servers/socket/2 ↩ - /bin/sh -c '/hurd/pfinet -i eth0 -a [...] > /tmp/stdout 2> /tmp/stderr' + /bin/sh -c 'exec >> /root/pfinet.log 2>&1 && date && ↩ + /hurd/pfinet -i eth0 -a [...]' $ [...] - $ cat /tmp/stdout + $ cat /root/pfinet.log + [date] NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP TCP: Hash tables configured (ehash 65536 bhash 65536) - $ cat /tmp/stderr pfinet: ../../hurd.work/pfinet/ethernet.c:196: ethernet_xmit: Unexpected error: (os/device) invalid IO size. (Trying to run [[GDB]] in this case was of no help -- due to a bug in GDB diff --git a/hurd/documentation.mdwn b/hurd/documentation.mdwn index 48fd017c..ec19e90b 100644 --- a/hurd/documentation.mdwn +++ b/hurd/documentation.mdwn @@ -1,5 +1,5 @@ [[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, -2009, 2011 Free Software Foundation, Inc."]] +2009, 2011, 2012 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 @@ -44,6 +44,8 @@ is included in the section entitled # Development + * [[RPC]]: our usage of *Remote Procedure Call*s. + * *[[The_GNU_Hurd_Reference_Manual|reference_manual]]*. * The *[[Hurd_Hacking_Guide]]*, an introduction to GNU Hurd and Mach diff --git a/hurd/interface/io_map.mdwn b/hurd/interface/io_map.mdwn new file mode 100644 index 00000000..11a59a51 --- /dev/null +++ b/hurd/interface/io_map.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2012 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]]."]]"""]] + +Used in [[glibc]] for implementing [[glibc/mmap]]. diff --git a/hurd/libstore/nbd_store.mdwn b/hurd/libstore/nbd_store.mdwn index 5874b162..8560fd44 100644 --- a/hurd/libstore/nbd_store.mdwn +++ b/hurd/libstore/nbd_store.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation, +[[!meta copyright="Copyright © 2007, 2008, 2009, 2012 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -10,3 +10,28 @@ is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] [[!meta title="nbd store: Linux-compatible network block device"]] + +[[!wikipedia "Network block device"]]. + + +# Servers + + +## [Network Block Device (TCP version)](http://nbd.sourceforge.net/) + +[[tschwinge]] once was testing this (years ago), and found it didn't work. +Perhaps the protocol was extended? + + +## [xNBD](https://bitbucket.org/hirofuchi/xnbd/) + + +## [jNbd](http://vanheusden.com/java/JNbd/) + + +## [BlackHole](http://vanheusden.com/java/BlackHole/) + + +# Open Issues + + * [[!GNU_Savannah_task 5722]] diff --git a/hurd/libthreads.mdwn b/hurd/libthreads.mdwn index 8b1a97e6..c8d819d4 100644 --- a/hurd/libthreads.mdwn +++ b/hurd/libthreads.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 2012 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 @@ -13,10 +13,14 @@ License|/fdl]]."]]"""]] # Internals +## Threading Model + +libthreads has a 1:1 threading model. + ## Threads' Death -C threads death doesn't actually free the thread's stack (and maybe not the +A thread's death doesn't actually free the thread's stack (and maybe not the associated Mach ports either). That's because there's no way to free the stack after the thread dies (because the thread of control is gone); the stack needs to be freed by something else, and there's nothing convenient to do it. There @@ -26,3 +30,5 @@ However, it isn't really a leak, because the unfreed resources do get used for the next thread. So the issue is that the shrinkage of resource consumption never happens, but it doesn't grow without bounds; it just stays at the maximum even if the current number of threads is lower. + +The same issue exists in [[libpthread]]. diff --git a/hurd/porting/guidelines.mdwn b/hurd/porting/guidelines.mdwn index 2618cd90..aabf0345 100644 --- a/hurd/porting/guidelines.mdwn +++ b/hurd/porting/guidelines.mdwn @@ -275,6 +275,7 @@ Oh, we should probably provide it. ## <a name="MAP_NORESERVE"> `MAP_NORESERVE` </a> Not POSIX, but we could implement it. +See [[glibc/mmap]]. ## <a name="O_DIRECT"> `O_DIRECT` </a> diff --git a/hurd/rpc.mdwn b/hurd/rpc.mdwn new file mode 100644 index 00000000..f4ddaab5 --- /dev/null +++ b/hurd/rpc.mdwn @@ -0,0 +1,121 @@ +[[!meta copyright="Copyright © 2012 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]]."]]"""]] + +[[Remote procedure call|/rpc]]s are the basis for about everything in the Hurd. +They're based on the [[Mach RPC mechanism (`mach_msg` system +call)|microkernel/mach/rpc]]. An RPC is made against a [[Mach +port|microkernel/mach/port]], which is the gateway to the [[translator]] that +will serve the RPC. Let's explore the case of `open`ing a file, and advancing +(`lseek`) ten bytes into it. The user program will be something like: + + #include <fcntl.h> + + int main(void) { + int fd = open("test.txt", O_RDONLY); + lseek(fd, 10, SEEK_CUR); + } + +Both `open` and `lseek` are functions provided by [[glibc]], which translates +these into the appropriate remote procedure calls. + +`open` first has to find its way to the actual translator serving that file, +but for a file on the root filesystem, what happens boils down to calling the +`dir_lookup` function against the root filesystem. This is an RPC from the +[[`fs` interface (see `fs.defs`)|interface/fs]]. The implementation of this +function is thus actually generated during the glibc build in +`RPC_dir_lookup.c`, based on the `fs.defs` file, using +[[microkernel/mach/MIG]]. This generated function essentially [[encodes the +parameters into a data buffer|idl]], and makes a `mach_msg` system call to send +the buffer to the root filesystem port, with the `dir_lookup` RPC ID. + +The root filesystem, for instance [[translator/ext2fs]], was sitting in its +main service loop (`libdiskfs/init-first.c:master_thread_function`), which +calls `ports_manage_port_operations_multithread`, which essentially simply +keeps making `mach_msg` system calls to receive [[microkernel/mach/message]]s, +and calls the demultiplexer on it, here the `diskfs_demuxer`. This +demultiplexer calls the demultiplexers for the various interfaces supported by +ext2fs. These demuxers are generated using MIG during the Hurd build. For +instance, the `fs` interface demultiplexer for [[diskfs|libdiskfs]], +`diskfs_fs_server`, is in `libdiskfs/fsServer.c`. It simply checks whether the +RPC ID is an `fs` interface ID, and if so uses the `diskfs_fs_server_routines` +array for calling the appropriate function corresponding to the RPC ID. Here +it's `_Xdir_lookup` which thus gets called. This one decodes the parameters +from the message data buffer, and calls `diskfs_S_dir_lookup`. + +`diskfs_S_dir_lookup` in the ext2fs translator does stuff to check that the +file exists, etc. and eventually creates a new port, which will represent the +open file, and a structure to keep information about it. It returns this new +port to its caller, `_Xdir_lookup`, which puts it into the reply message data +buffer and returns. `ports_manage_port_operations_multithread` then calls +`mach_msg` to send that port to the user program. + +The `mach_msg` call in the user program thus returns, returning the port, +decoded by `dir_lookup`. glibc adds a new slot to its +[[glibc/file_descriptor]] table, and records the port in it. + +`lseek` is simpler. The glibc implementation simply calls the `__io_seek` +function against the port of the file descriptor. This is an RPC from the +[[`io` interface (see io.defs)|interface/io]]. As explained above, the +implementation is thus in `RPC_io_seek.c`, it encodes parameters and makes a +`mach_msg` system call to the port of the file descriptor with the `io_seek` +RPC ID. + +In the root filesystem, it's now the demultiplexer for the `io` interface, +`diskfs_io_server`, which will recognize the RPC ID, and call `_Xio_seek`, +which retrieves the data structure for the port, and calls `diskfs_S_io_seek`. +The latter simply modifies ext2fs' internal data structure to account for the +file position change, and returns the new position. `_Xio_seek` encodes the +position into the reply message, which is sent back by +`ports_manage_port_operations_multithread` through `mach_msg`. + +The `mach_msg` call in the user program thus returns the new offset, decoded by +`__io_seek`. `lseek` can then return it to the user application. + + +When hacking, one usually does *not* have to keep all that in mind. All one +needs to remember (or look up) is that when the application program calls +`open`, the glibc implementation actually calls `dir_lookup`, which triggers a +call to `diskfs_S_dir_lookup` in the ext2fs translator. When the application +program calls `lseek`, the glibc implementation calls `__io_seek`, which +triggers a call to `diskfs_S_io_seek` in the ext2fs translator. And so on... + + +# Questions and Answers + +## How do I know whether a function is an RPC or not? + +Simply `grep` the function name (without leading underscores) in the +`/usr/include/hurd/*.defs` files. + + +## Why is it a libdiskfs function that get called? + +Because the filesystem serving the file, ext2fs, is [[libdiskfs]]-based (see +`HURDLIBS = diskfs` in `ext2fs/Makefile`). Other translators are +[[libnetfs]]-based or [[libtrivfs]]-based. `grep` for RPC names in those +according to what your translator is based on. + + +## How do I know which translator the RPC gets into? + +Check the type of file whose port the RPC was made on. Most files are handled +by the translator which is mounted where the files are opened. Some special +files are handled by particular translators: + + * `PF_LOCAL`/`PF_UNIX` sockets are served by [[translator/pflocal]], see + [[hurd/networking]]; + * `PF_INET`/`PF_INET6` sockets are served by [[translator/pfinet]], see + [[hurd/networking]]; + * named sockets (also known as FIFOs) are served by [[translator/fifo]]. + + +# See Also + + * [[hurd/debugging/rpctrace]] diff --git a/hurd/running.mdwn b/hurd/running.mdwn index a14106e1..41855433 100644 --- a/hurd/running.mdwn +++ b/hurd/running.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009, 2011 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2009, 2011, 2012 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 @@ -17,11 +17,10 @@ There are several different ways to run a GNU/Hurd system: * [[microkernel/mach/gnumach/ports/Xen]] - In Xen * [[Live_CD]] * [[QEMU]] - In QEMU +* [[chroots|chroot]] need a couple of tricks to work properly. * [[VirtualBox]] - In VirtualBox * [[vmware]] (**non-free!**) * [[FAQ]] * [[Public_hurd_boxen]] - -[[chroots|chroot]] need a couple of tricks to work properly. diff --git a/hurd/chroot.mdwn b/hurd/running/chroot.mdwn index 60bf47b7..29b00a8f 100644 --- a/hurd/chroot.mdwn +++ b/hurd/running/chroot.mdwn @@ -8,15 +8,15 @@ 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]]."]]"""]] -This documents the currently-needed tricks to successfully build a chroot in -GNU/Hurd. +This documents the currently-needed tricks to successfully build a +[[glibc/chroot]] in GNU/Hurd. # Preparation For proper translator startup, the chroot storage needs to be handled by a separate translator, for instance: - # dd < /dev/zero > storage + # dd [...] < /dev/zero > storage # mke2fs storage # settrans -c chroot /hurd/ext2fs $PWD/storage @@ -29,13 +29,15 @@ Debootstrap should be able to build the content: # Tricks One current issue to know about chroots is that since passive translators (e.g. -/servers/socket/pflocal) are started by the root translator, which is not aware +`/servers/socket/1`) are started by the root translator, which is not aware of the chrooting, these passive translators are started non-chrooted, leading to a few issues. +[[!tag open_issue_hurd]] ## Sockets -Since the passive pflocal translator will not be chrooted, local socket creation +Since the passive [[translator/pflocal]] translator will not be chrooted, local +socket creation will actually happen in the root filesystem. To make things work correctly the programs inside the chroot need to be able to access them: @@ -45,7 +47,8 @@ programs inside the chroot need to be able to access them: ## Network -Unless using a separate IP for the chroot, it is preferrable to share the pfinet translator: +Unless using a separate IP for the chroot, it is preferrable to share the +[[translator/pfinet]] translator: # settrans chroot/servers/socket/2 /hurd/firmlink /servers/socket/2 # settrans chroot/servers/socket/26 /hurd/firmlink /servers/socket/26 diff --git a/hurd/running/debian/after_install.mdwn b/hurd/running/debian/after_install.mdwn index 419940a7..72ea70a9 100644 --- a/hurd/running/debian/after_install.mdwn +++ b/hurd/running/debian/after_install.mdwn @@ -1,6 +1,8 @@ First steps after installation. -See http://www.debian.org/ports/hurd/hurd-install for configuration bits and tips and tricks. +See <http://www.debian.org/ports/hurd/hurd-install> for configuration bits and +tips and tricks. + # Setup GRUB diff --git a/hurd/running/debian/dhcp.mdwn b/hurd/running/debian/dhcp.mdwn index 8d351aae..afa46799 100644 --- a/hurd/running/debian/dhcp.mdwn +++ b/hurd/running/debian/dhcp.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 2012 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,16 +10,16 @@ License|/fdl]]."]]"""]] [[!tag open_issue_porting]] -In order to use DHCP, you need to install the `ifup` and `isc-dhcp-client` -packages, and manually create the following two symbolic links: +In order to use DHCP, you need to install the `ifupdown` and `isc-dhcp-client` +packages, and manually create the following symbolic link: - # ln -s ../rcS.d/S06ifupdown-clean ../rcS.d/S11networking /etc/rc.boot/ + # ln -s ../rcS.d/S10networking /etc/rc.boot/ -During execution at boot time, the `S11networking` script will emit some error +During execution at boot time, the `S10networking` script will emit some error messages while trying to configure the loopback interface. These are not fatal. -Debian GNU/Hurd doesn't currently execute's Debian standard `/etc/rcS.d/*` boot +Debian GNU/Hurd doesn't currently execute Debian standard `/etc/rcS.d/*` boot scripts, but has its own `/libexec/rc` script -- which integrates scripts from `/etc/rc.boot/` instead. diff --git a/hurd/running/qemu.mdwn b/hurd/running/qemu.mdwn index 512ea602..3648c7d6 100644 --- a/hurd/running/qemu.mdwn +++ b/hurd/running/qemu.mdwn @@ -105,6 +105,16 @@ 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. +IRC, freenode, #hurd, 2012-08-29: + + <braunr> youpi: do you remember which linux versions require the + -no-kvm-irqchip option ? + <braunr> your page indicates 2.6.37-38, but i'm seeing weird things on + 2.6.32 + <braunr> looks like a good thing to use that option all the time actually + <gnu_srs> seems like kvm -h says: -no-kvm-irqchip and man kvm says: + -machine kernel_irqchip=off + /!\ 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. diff --git a/hurd/settrans/discussion.mdwn b/hurd/settrans/discussion.mdwn index c9ec4d34..74f1c8f5 100644 --- a/hurd/settrans/discussion.mdwn +++ b/hurd/settrans/discussion.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 2012 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 @@ -16,3 +16,24 @@ License|/fdl]]."]]"""]] <antrik> ugh... I just realized why settrans -a without -f doesn't generally work on filesystem translators <antrik> obviously, it needs -R too! + + +# IRC, freenode, #hurd, 2012-08-17 + + <antrik> youpi: no, only the -g is redundant; i.e. -ga is the same as -a + <antrik> (actually, not redundant, but rather simply meaningless in this + case) + <antrik> -g tells what to do with an active translator *when a passive one + is changed* + <antrik> if no passive one is changed, it does nothing + <antrik> (and I realized that after using the Hurd for only 6 years or so + ;-) ) + <braunr> it's not obvious + <antrik> braunr: indeed. it's not obvious at all from the --help output :-( + <antrik> not sure though how to make it clearer + <braunr> the idea isn't obvious + <braunr> perhaps telling that "setting a passive translator" also applies + to removing it, i.e. setting it to none + <antrik> braunr: well, the fact that a translator is unset by setting it to + nothing is unclear in general, not only for passive translator. I agree + that pointing this out should make things much more clear in general... diff --git a/hurd/subhurd/discussion.mdwn b/hurd/subhurd/discussion.mdwn index 3449edcd..c4fc047f 100644 --- a/hurd/subhurd/discussion.mdwn +++ b/hurd/subhurd/discussion.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 2012 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,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_documentation]] +[[!tag open_issue_documentation open_issue_hurd]] -IRC, freenode, #hurd, 2011-08-10 + +# IRC, freenode, #hurd, 2011-08-10 < braunr> youpi: aren't sub-hurds actually called "neighbor hurds" ? < youpi> no idea @@ -67,3 +68,92 @@ IRC, freenode, #hurd, 2011-08-10 < 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 + + +# IRC, freenode, #hurd, 2012-07-31 + + <gg0> subhurd seems like bsd jail (tried none of them) + <antrik> gg0: nope. BSD jails are mostly chroot AIUI. subhurd is quite + different + <antrik> gg0: you actually boot a completely new system instance + <antrik> complete with all the Hurd servers, UNIX daemons etc. + <braunr> jails are between subhhurds and chroots :p + <braunr> i suppose there is nothing against making the root server of the + subhurd use a file instead of a raw disk, is there ? + <gg0> well, I said jails cos afaik are more isolated from real system than + chroots + <braunr> yes + <gg0> maybe comparing subhurd to virtual machines would be more + appropriated then + <braunr> they're not VMs either + <gg0> say chroot -> jail -> subhurd -> vm ? + <braunr> unless you consider the microkernel to be a hypervisor, with its + own architecture, which some actually do + <braunr> gg0: something like that, yes + <gg0> [system-in-system evolution] + <braunr> a subhurd is an operating system instance + <braunr> i think the closest analogy you can get is openvz + <antrik> yeah, I'd also consider it closest. but it's still quite + different: with OpenVZ, the kernel facilities are only logically + isolated; but they use the same kernel code. with subhurds, most of the + system facilities are independent + + +# IRC, freenode, #hurd, 2012-08-03 + + <antrik> hm... are Mach task IDs exposed to userspace? + <braunr> antrik: ids ? + <braunr> antrik: what do you call a mach task id ? + <antrik> task have numeric IDs in the kernel + <antrik> I wonder whether these are ever exposed to userspace + <braunr> i'm not sure + <braunr> i don't remember the had numeric IDs + <braunr> they* + <antrik> well, perhaps I'm making things up... but I believe I saw such IDs + in the debugger and/or in error messages + <braunr> probably their address + <braunr> or creation time orpc_sample + <antrik> braunr: well, any unique ID would do + <braunr> antrik: yes but i was wondering what kdb would actually show + <antrik> I just realised that it would be useful for debugging accross + subhurds or kernel/userspace if some kind of unique task IDs could be + shown in ps output + <braunr> yes + <braunr> this requires some thought though + <braunr> ps shouldn't show that + <braunr> there should be mach specific commands i suppose + <braunr> but then, gdb and other tools wouldn't have access to subhurd + tasks either + <antrik> why shouldn't ps show that? I don't think it's any more sensitive + information than all the other stuff ps shows... + <braunr> it doesn't feel right + <braunr> i would want my system instances to be truely isolated + <braunr> and use special "cross instance" facilities + <braunr> when necessary + <antrik> that's completely orthogonal to what I'm talking about + <braunr> like eth-multiplexer + <braunr> you seem to be talking about security + <braunr> or privacy + <antrik> we discussed such options when zhengda worked on rootless subhurd + <antrik> no, I'm talking about convenient debugging + <braunr> right + <braunr> i don't think it'zs orthogonal here + <braunr> if we increase separation, it becomes less convenient + <antrik> for debugging purposes you would *not* use the isolation options + <braunr> ok so you propose two modes of operations + <antrik> BTW, as an isolated subhurd relies on the parent, it makes no + sense to hide subhurd tasks from the parent hurd -- only hide parent hurd + task from the subhurd + <braunr> agreed + <antrik> so even with an isolated subhurd global task IDs would still be + useful + + +# IRC, freenode, #hurd, 2012-08-06 + + <braunr> antrik: if i'm right, the root file system executable is read from + the parent, right ? + <antrik> braunr: probably... I'm not sure about that part + <braunr> antrik: i've installed the same packages in both the main and + subhurds to be sure + <braunr> and to have the right binary and debugging symbols in gdb anyway diff --git a/hurd/translator.mdwn b/hurd/translator.mdwn index d504b41f..37f4e8bc 100644 --- a/hurd/translator.mdwn +++ b/hurd/translator.mdwn @@ -93,6 +93,8 @@ The [[concept|concepts]] of translators creates its own problems, too: * [[magic]] * [[unionfs]] * [[nfs]] +* [[symlink]] +* [[firmlink]] * ... diff --git a/hurd/translator/exec.mdwn b/hurd/translator/exec.mdwn index d5b6bfbc..54abba7e 100644 --- a/hurd/translator/exec.mdwn +++ b/hurd/translator/exec.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009, 2012 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,3 +10,5 @@ License|/fdl]]."]]"""]] The *exec* server, listening on `/servers/exec`, is responsible for preparing the execution of processes. + + * [[open_issues/exec_memory_leaks]]. diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn index 8e15d1c7..13a1d9ec 100644 --- a/hurd/translator/ext2fs.mdwn +++ b/hurd/translator/ext2fs.mdwn @@ -20,6 +20,8 @@ License|/fdl]]."]]"""]] * [[metadata_caching]] + * [[internal_allocator]] + ## Large Stores @@ -87,6 +89,20 @@ small backend stores, like floppy devices. <youpi> which can be quite probable +## Sync Interval + +[[!tag open_issue_hurd]] + + +### IRC, freenode, #hurd, 2012-10-08 + + <braunr> btw, how about we increase our ext2 sync interval to 30 seconds, + like others do ? + <braunr> not really because others do it that way, but because it severely + breaks performance on the hurd + <braunr> and 30 seems like a reasonable amount (better than 5 at least) + + # Documentation * <http://e2fsprogs.sourceforge.net/ext2.html> diff --git a/hurd/translator/ext2fs/internal_allocator.mdwn b/hurd/translator/ext2fs/internal_allocator.mdwn new file mode 100644 index 00000000..f3678a28 --- /dev/null +++ b/hurd/translator/ext2fs/internal_allocator.mdwn @@ -0,0 +1,39 @@ +[[!meta copyright="Copyright © 2012 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, 2012-07-30 + + <mcsim> Why for big buffers in ext2fs used own allocator, that just + allocates many pages at once, instead of using malloc? + <mcsim> i.e. can I replace it with malloc, because it just complicates + things? + <braunr> mcsim: probably because of alignment + <braunr> what gets complicated by that ? + <mcsim> braunr: than valloc? + <mcsim> braunr: this allocator allows to allocate only buffer with size of + vm_page_size. + <mcsim> valloc just would be clearer. + <braunr> valloc ? + <braunr> valloc is obsolete + <mcsim> braunr: than memalign or posix_memalign? + <mcsim> memalign obsolete too... would posix_memalign be eligible? + <braunr> mcsim: why memalign instead of the custom allocator ? + <mcsim> because, I think, it is clearer. Also, since I need to allocate any + amount of pages, not just one, I have to edit custom allocator. Although + it is not hard, but using ready stuff seems more sane for me. + <mcsim> braunr: ^ + <braunr> right, but make sure posix_memalign doesn't create too much + overhead + <mcsim> braunr: what kind of overhead? + <braunr> fragmentation + <braunr> i assume the glibc implementation is careful about that, but still diff --git a/hurd/translator/firmlink.mdwn b/hurd/translator/firmlink.mdwn new file mode 100644 index 00000000..038879db --- /dev/null +++ b/hurd/translator/firmlink.mdwn @@ -0,0 +1,22 @@ +[[!meta copyright="Copyright © 2012 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, 2012-07-20 + + <infinity0> does hurd have equivalent of mount --bind yet? + <kilobug> infinity0: unionfs with just one back-end ? + <infinity0> ah cool i'll try thaty + <kilobug> there may be something better, but that's the one I know about ;) + <braunr> infinity0: firmlinks + <infinity0> ah thanks i'll look that up + <kilobug> braunr: oh, true, I forgot about that one diff --git a/hurd/translator/nfs.mdwn b/hurd/translator/nfs.mdwn index bf24370a..81372204 100644 --- a/hurd/translator/nfs.mdwn +++ b/hurd/translator/nfs.mdwn @@ -10,6 +10,11 @@ License|/fdl]]."]]"""]] Translator acting as a NFS client. +Only NFSv2/v3 is currentl supported. + +[[!tag open_issue_hurd]]There are a few unmerged changes on a former GSoC +project's topic-branch. + # See Also diff --git a/hurd/translator/pfinet/ipv6.mdwn b/hurd/translator/pfinet/ipv6.mdwn index 5afee0c6..d30cc850 100644 --- a/hurd/translator/pfinet/ipv6.mdwn +++ b/hurd/translator/pfinet/ipv6.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2007, 2008, 2010 Free Software Foundation, +[[!meta copyright="Copyright © 2007, 2008, 2010, 2012 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]]."]]"""]] [[Stefan_Siegl|stesie]] has added IPv6 support to the pfinet [[translator]]. This was [Savannah task #5470](http://savannah.gnu.org/task/?5470). @@ -55,3 +55,18 @@ Quite the same, but with static IPv6 address assignment: # Missing Functionality Amongst other things, support for [[IOCTL]]s is missing. + + +## IRC, freenode, #hurd, 2012-12-10 + +[[!tag open_issue_hurd]] + + <braunr> looks like pfinet -G option doesn't work + <braunr> if someone is interested in fixing this (it concerns static IPv6 + routing) + <braunr> youpi: have you ever successfully used pfinet with global + statically configured ipv6 addresses ? + <youpi> never tried + <braunr> ok + <braunr> i'd like to set this up on my VMs but it looks bugged :/ + <braunr> i can't manage to set correctly set the gateway diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn index 4f6492ed..e71ea02b 100644 --- a/hurd/translator/procfs/jkoenig/discussion.mdwn +++ b/hurd/translator/procfs/jkoenig/discussion.mdwn @@ -215,7 +215,8 @@ Needed by glibc's `pldd` tool (commit # `/proc/self/exe` -[[!message-id "alpine.LFD.2.02.1110111111260.2016@akari"]] +[[!message-id "alpine.LFD.2.02.1110111111260.2016@akari"]]. Needed by glibc's +`stdlib/tst-secure-getenv.c`. # `/proc/[PID]/fd/` @@ -278,6 +279,9 @@ Needed by glibc's `pldd` tool (commit # `/proc/[PID]/maps` +[[!GNU_Savannah_bug 32770]] + + ## IRC, OFTC, #debian-hurd, 2012-06-20 <pinotree> bdefreese: the two elfutils tests fail because there are no @@ -313,3 +317,23 @@ Needed by glibc's `pldd` tool (commit * pinotree has a local work to add the /proc/$pid/cwd symlink, but relying on "internal" (but exported) glibc functions + + +# "Unusual" PIDs + +Not actually related to procfs, but here seems to be a convenient place for +filing these: + + +## IRC, freenode, #hurd, 2012-08-10 + + <braunr> too bad the proc server has pid 0 + <braunr> top & co won't show it + + +## IRC, OFTC, #debian-hurd, 2012-09-18 + + <pinotree> youpi: did you see + https://enc.com.au/2012/09/careful-with-pids/' + <pinotree> ? + <youpi> nope diff --git a/hurd/translator/random.mdwn b/hurd/translator/random.mdwn index afb76953..9fc975f2 100644 --- a/hurd/translator/random.mdwn +++ b/hurd/translator/random.mdwn @@ -31,7 +31,7 @@ but they are not yet in the default installation. the internals. * [Entropy Gathering Daemon](http://egd.sourceforge.net/). - * [request for packaging](http://bugs.debian.org/145498). + * [[!debbug desc="request for packaging" 145498]]. * [OSKit Entropy Patch](http://lists.gnu.org/archive/html/bug-hurd/2003-01/msg00000.html) from |