Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Sleeping Cousins

Hurd Traffic #74 For 3 Jan 2001

Editor: Zack Brown

By Paul Emsley  and  Zack Brown

Mach 4 | Hurd Servers | Debian Hurd Home | Debian Hurd FAQ | debian-hurd List Archives | bug-hurd List Archives | Hurd Reference Manual | Hurd Installation Guide | Cross-Compiling GNUMach | Hurd Hardware Compatibility Guide

Table Of Contents


Want to help write KC Debian Hurd? See the KC Authorship page the KC Debian Hurd homepage, and the Thread Summary FAQ. Send any questions to the KCDevel mailing list.

Mailing List Stats For This Week

We looked at 56 posts in 325K.

There were 32 different contributors. 7 posted more than once. 10 posted last week too.

The top posters of the week were:

1. Memory-Based Filesystem For The Hurd

19 Dec 2000 - 26 Dec 2000 (14 posts) Archive Link: "A memory-based filesystem for the lazy [or impatient]"

Summary By Zack Brown

People: Ognyan KulevFarid HajjiJim Franklin

Farid Hajji posted code for a memory-based filesystem. Jim Franklin asked for a URL to link to, and Ognyan Kulev replied:

I added it to Hurd Web page which it is unaccessible now (damned flood attacks). But it is available in the mirror

Sourceforge have implemented releasing files. Perhaps it can be used to upload such cool stuff. I mean in

2. Keyboard Customization

22 Dec 2000 - 26 Dec 2000 (2 posts) Archive Link: "Keyboard settings for UK keyboard"

Summary By Paul Emsley

People: Frederico MuñozDavid NearyPaul Emsley

David Neary asked how to customise the keyboard. Frederico Muñoz replied: "Marcus has a script (in perl I think) that does that, just check his dir at; it has the script and also a config file set for german, change that one according to your keymap and run the script. You should have no problems since you do not need dead keys or special fonts; I also had problems with two keys in the bottom left, and that even with a portuguese keyboarf (strangely the german and portuguese keymaps are the basicaly the same in non alphanumeric chars, like /()[]+* etc.) "

(ed. [Paul Emsley] I think that the script to which Frederico was referring is in keymap.tar.gz.)

3. libdb2 Patching Problem

28 Dec 2000 - 30 Dec 2000 (4 posts) Archive Link: "libdb2 or Hurd issue?"

Summary By Paul Emsley

Topics: POSIX

People: Marcus BrinkmannJason Felice

In a follup to his previous message, Jason Felice discussed his problems with O_RDONLY/O_WRONLY/O_RDWR in certain packages. He posted a piece of libdb2 source code comment that illustrated the problem: Convert POSIX 1003.1 open(2) flags to DB flags. Not an exact science as most POSIX implementations don't have a flag value for O_RDONLY, it's simply the lack of a write flag.

Marcus Brinkmann replied that he thought that they had fixed this some thime ago. He added "Everything that is POSIXish is a Hurd thing. Mach doesn't know what POSIX is."

Realising that this problem had already been seen and fixed provoked Jason to rant:

I'm getting sick of this Debian stuff, I keep getting dead-ended. This is painful. I've packaged lots of stuff with RPM, where I don't have to wait on the maintainer (because I can send the patch *and* distribute the RPM), or other architectures (because patches distributed with the RPM can be conditionally applied just for that arch). Am I missing something? It's almost painful restraining myself from making an RPM-based Hurd distribtution - I only do it because I figure the duplication of effort would hurt the project (although I've given it some thought lately, and I'm not sure that assumption is correct - as long as the projects share the same patch pool and dialog).

Having to keep pace with the i386 distro is a *very* big albatross at such an early stage in the game, especially since most of the package maintainers aren't going to be keen to the Hurd's particular issues.

I kicked out six packages a day, debugged and tested, on CLUG's (now defunct) secure-linux project, and I practically built a distribution from scratch at my previous employer (it was sort of based on RH5.2) - complete with boot and installation procedures. Here, I just can't seem to get a single package out.

To which Marcus replied: "For such subtle and Hurd specific stuff, nobody can be blamed. We have to find them ourself and report them to the appropriate people. This smells like an upstream bug ;) Could you try to find the latest upstream source and check this?"

4. New tmpfs Filesystem

28 Dec 2000 - 30 Dec 2000 (2 posts) Archive Link: "new tmpfs filesystem"

Summary By Zack Brown

Topics: FS: ext2

People: Roland McGrathAlexey Dejneka

Roland McGrath announced:

I've written a new in-core filesystem called tmpfs. This new code is checked into the hurd cvs repository under hurd/tmpfs, but not built by default. You can try building it by configuring your hurd build directory and then doing "cd tmpfs; make". Please let me know about any errors you find (you can report them here). I have not even compiled this code, since I don't have a complete development environment handy. But since it is in the repository and available to anyone who cares, I thought I would mention it here.

This filesystem is similar to tmpfs in SunOS, and vaguely similar to mfs in BSD. Whereas mfs is essentially a regular filesystem (ufs) stored in virtual memory instead of a disk, this tmpfs does not use a normal filesystem format at all. It is written using the libdiskfs library and so acts very much like the ext2fs and ufs filesystems do. But it stores its meta-data and directories directly in simple in-core data structures, and uses memory objects implemented by the default pager to hold the contents of regular files.

You start this filesystem as a translator like other filesystems:

settrans -ca /test-tmp /hurd/tmpfs 100M

It requires an argument saying how much virtual memory to use for the filesystem data (and meta-data). The memory and/or swap space is is not used just by running the filesystem. It mainly provides something for df to print, and sets a limit at which you will get "Disk full" errors. Only the amount of space actually used (as shown by df) consumes virtual memory. You can change the limit later with "fsysopts /test-tmp 200M".

That is, that's what it will do if it works. You'll probably have to debug it a bit for me.

Alexey Dejneka posted a patch to allow Roland's code to compile, but there was no discussion.







Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.