Some weeks after Neal Walfield [interview] implemented POSIX semaphores for libpthread [story], Marcus Brinkmann has now implemented SysV shared memory for the GNU Hurd in glibc, based on some earlier work done by Neal. This was probably the last commonly used POSIX feature missing in the Hurd, and having shared memory available will make several programs work much better. Success has already been reported with mplayer; it was very cludgy before and works smoothly with shared memory enabled.
From: Marcus Brinkmann Subject: [PATCH] system V shared memory support for the Hurd in glibc Date: Mon, 11 Jul 2005 23:52:35 +0200 Hi, this patch is for glibc, but it needs to get more testing before it can go in. Please give it a good beating. This patch adds System V Shared Memory support to the GNU Hurd. There is a small extension to the filesystem interface that allows the filesystem to report to the application if the file may currently be mapped by other applications. A separate patch to report this information from ext2fs and other filesystems will follow. These features are implemented: Creating shared memory segments. Attaching to them. Detaching from them. Removing them. Get the uid/gid/mode. These features are not, and can't be within the standard filesystem interface: Getting the exact number of nattch (not even if it is just 1). Getting pid/lpid (always zero). Getting time stamps (last attach, last detach, last modification). Getting the cuid/cgid (always just uid/gid). Verifying the cuid/cgid when accessing. Compatibility note: Most programs should work. POSIX says RMID removes all mappings, but no system does it that way (and neither do we). From: Marcus Brinkmann Subject: Re: [PATCH] system V shared memory support for the Hurd in glibc Date: Tue, 12 Jul 2005 00:20:05 +0200 At Mon, 11 Jul 2005 23:52:35 +0200, Marcus wrote: > > Hi, > > this patch is for glibc, but it needs to get more testing before it > can go in. Please give it a good beating. I should add some information on how to test this. The shm node is /dev/shm. Normally, tmpfs is installed on this node by MAKEDEV. But this won't work yet, because tmpfs is broken (d'oh). So, you put on the node an ext2fs filesystem and it will work. For example, you can use a ramdisk. Or just don't set any translator on it and use the root filesystem. In either case, you need to use the --no-inherit-dir-group (--sysvgroups) option so the group permissions will be right. The permissions on the node should be like for the /tmp directory: world rwx, sticky bit set. Below is a temporary patch for ext2fs to support the bit used for nattch. Only few programs will require this, though. Thanks, Marcus
Applicability to Linux?
Can some of these HURD ideas be incorporated into the Linux kernel? I know it's a different design (monolithic vs. microkernel), but ideas are ideas. I know HURD wants to be different from the ground up, but how radically different is it that you can't take code from Linux and put it into the HURD, and vice versa?
Personally, I wish the two would just work together...
Re: Applicability to Linux?
First off, this has nothing to do with shared memory, as Linux supports that since ages. About direct code-reuse, GNU Mach (the underlying microkernel) currently uses Linux drivers through some glue code. Incoporating Linux code into the Hurd is less easy, for one because the FSF requires copyright assignments for non-trivial contributions (as for the other GNU projects) and also because the Hurd runs in user space while Linux is kernel space by definition; their targets are thus different. That said, the currently used network stack in the Hurd is also ported from Linux.
About the opposite direction, namely introducing Hurd features into Linux, this more or less happens independently. FUSE (File Systems in User Space) and dnotify/inotify for file system alteration notifications are two examples for long-standing Hurd features now becoming available on Linux as well.
Michael
About direct code-reuse, GNU
About direct code-reuse, GNU Mach (the underlying microkernel) currently uses Linux drivers through some glue code.
I think the Hurd is in the process of switching over to the L4 kernel and Mach is being abandoned. I wonder if the drivers will still be able to work under Hurd when this is done.
Re: About direct code-reuse, GNU
There are basically three options here:
1. Port some basic stuff from anywhere, just to get Hurd/L4 started. Matthieu Lemerre has done this for a basic IDE driver already.
2. Implement the proposed device-driver-framework and write all drivers from scratch, in user-space. Nobody has stepped up to do either, yet.
3. Use the work done by the Karlsruhe research group on virtualization and legacy code reuse, i.e. basically run a stripped-down Linux instance in a virtual machine (similar to VMWare) besides Hurd/L4 but on top of L4 and use that for drivers.
Solution 3 seems to be the most promising right now.
Michael
Solution 3 has to be the *dum
Solution 3 has to be the *dumbest* idea I've read in a while.
It's the quick and dirty fix
It's the quick and dirty fix and it won't encourage anyone to take the Hurd seriously or commit to it. What it does allow are major changes such as a new microkernel etc, as far as I know the Hurd is still changing.
Re: It's the quick and dirty fix
It was always the goal of the Hurd to explore the limits of operating system design, device drivers are considered a necessary evil to get the system working on real world hardware by the core developers. There will hopefully be people caring about them, but the interesting parts are the core design, and reusing legacy code for device drivers seems perfectly valid to me. Even moreso as the Karlsruhe guys seem to have found a pretty performant solution, see http://l4ka.org/projects/virtualization/drivers.php for more information.
Michael
heh - see MacOS X
IIRC, Solution 3 is basically what MaxOS X does. It uses a FreeBSD variant kernel running on Mach for most of the device drivers.