Some bits about this, some bits about that.

Controlling TTY

Hurd controlling tty behavior is generally consistent with BSD's, including TIOCSCTTY. Linux also has TIOCSCTTY and it is harmless to use it there. But BSD and Hurd never do an implicit TIOCSCTTY (hence our O_NOCTTY is zero).

C.f. http://lists.gnu.org/archive/html/bug-hurd/2009-10/msg00030.html and the following messages.

Sinals

Unix signals are implemented in glibc.

In every process, signals are handled in a separate signal thread.

[Why does kill hang sometimes?]
<youpi> kill send the signal to the process
<youpi> if the process is hung, killing waits
<youpi> signals should be just asynchronous, but apparently for some reason
  Roland & co wanted some syunchronization

open issue glibc

tinyproxy works fine for HTTP connections, but fails to proxy HTTPS ones:

ERROR     Jun 12 14:58:51 [20676]: relay_connection: select() error "Interrupted system call". Closing connection (client_fd:7, server_fd:8)

This is supposedly due to the already known select bug, which is a open issue glibc.

ptrace has some issues (sysdeps/mach/hurd/ptrace.c).

• Our implementation (and the generic one in misc/ptrace.c) differ from the Linux one (sysdeps/unix/sysv/linux/ptrace.c) w.r.t. handling of...

  • the third argument: int data vs. void *data;

  • void *addr2 -- Linux doesn't have this, but we provide some additional functionalty using this;

  • function declaration: Linux has long int ptrace (enum __ptrace_request __request, ...) __THROW, we have int ptrace (enum __ptrace_request __request, ...);

  • interface do differ, e.g., Linux' PTRACE_GETREGS uses void *data, we use void *addr for returning the struct, and in Linux this is a struct user_regs_struct from linux/user.h, and for us it is a struct i386_thread_state from mach/i386/thread_status.h;

  • Linux probides some functionality that we don't provide, e.g., PTRACE_SINGLESTEP.

• Some parts are wrongly implemented, e.g., PTRACE_GETREGS and PTRACE_SETREGS both do the same thing.

• return values are wrong, e.g., return EOPNOTSUPP should instead set errno = EOPNOTSUPP and return -1 in a few places (but not with the three PTRACE_PEEK* requests.

Also consider the sysdeps/generic/sys/ptrace.h and sysdeps/unix/sysv/linux/sys/ptrace.h files.

Just like in other Unix systems one can, for example, use fdisk or parted to manage hard disks' partition tables. After doing changes to a disk's partition table, the kernel has to be instructed to reinitialize its internal data structures: where does a partition begin, where does it end, etc.

With fdisk and friends this is done on Linux with the BLKRRPART IOCTL, which is used to tell the kernel to reread the disk's partition table.

parted also uses this interface on Linux, but for GNU Hurd, the corresponding function, libparted/arch/gnu.c (gnu_disk_commit), doesn't do anything at all. The infrastructure in GNU Mach is already there, linux/src/drivers/block/ide.c (ide_ioctl) <BLKRRPART> and linux/src/drivers/scsi/sd_ioctl.c (sd_ioctl) <BLKRRPART>, but the IOCTL needs to be routed from libparted through glibc's Hurd IOCTL interface, through Hurd's libstore, to GNU Mach.

This is not a huge project, and actually one that is suitable for someone who wants to start with hacking the system.

<tschwinge> # settrans -P -a /servers/socket/2 /hurd/pfinet -i eth0 -a 192.168.10.61 -g 192.168.10.1 -m 255.255.255.0
<tschwinge> Translator pid: 2289
<tschwinge> Pausing...
<tschwinge> pfinet: /build/buildd/hurd-20080607/build-tree/hurd/libports/create-internal.c:115: _ports_create_port_internal: Unexpected error: (ipc/mig) wrong reply message ID.
<neal> it would be nice to print out the id when those sorts of errors occur.

This error code is MIG_REPLY_MISMATCH and can be returned in GNU Mach's kern/exception.c (exception_parse_reply), in MIG-generated code, see user.c (WriteCheckIdentity), and in glibc's sysdeps/mach/hurd/ioctl.c (__ioctl).