The first linux.conf.au, a worthy successor to CALU-99, the Confernece of Australia Linux Users in late 1999. Linux.conf.au was held in Sydney at the University of New South Wales, where I work, so I had to go. I even gave a WorkInProgress on Linux Raid development.
An NFS filehandle stores information to identify a filesystem (or directory in the filesystem that is the export point) and a file within that filesystem.
Identifying the file within the filesystem is now handled fairly well, but there are problems with identifying the filesystem.
I've just installed aether-1.4 for this website and made a few enhancements that I might submit one day.
They include allowing a blog to select entries from another blog based on tags in the [entry] field. Thus my
Also a blog can show just a list of pages (or the summaries there-of), so my
Other changes I am contemplating include:
I have just released a new version of mdadm - 1.6.0.
Mdadm is my tool for managing Linux Software RAID arrays.
This release included initial support for a --grow mode that allows resizing on-line arrays. Naturally this requires kernel support to be able to work. The 2.6.7-rc2-mm1 Linux kernel has support for changing the active size of component devices and changing the number of drives in a RAID1.
I hope to add support for adding drives to a linear array soon, and adding drives to a RAID5 eventually.
I had hoped to get support for the new-style superblocks into this release, but it just didn't happen. Maybe next time.
In my Linux kernel development work, I often apply patches to files that have changed since the patch was created. Sometimes these patches fail to apply for trivial reasons.
About a year ago I wrote a program called
When I apply a patch that fails, I would like to be able to see exactly why it failed, and what wiggle would do to fix it. But to do that I currently have to grovel around in various files. I would be nice if this was more automatic.
What I am envisaging is a new patch application tool. Let's call it vpatch.
Pipes are a great tool for connecting programs together. It is a real joy to be able to connected various Unix tools together in a pipeline. One of my favourite is
... | sort | uniq -c | sort -n
to get a frequency count of some collection of lines (often from logs).
It is worth noting that pipes are only one of the enabling technologies for this sort of thing. There are two others.
The first is the Bourne shell and derivative. The fact that the shell makes it easy to create pipelines is fundamental to their success.
The other is the common practice of having program receive and generate un-decorated line-oriented data. This 'common language' for passing data around is essential for pipelines to work. It is worth noting that while line-oriented is very standard, having fields in the lines is very ad-hoc. Many commands allow you to act of fields, but they all do so in different ways. If you compare sort, cut, uniq and others you will see a complete lack of uniformity. This something that a successor to pipes would need to address.
So a successor to pipes needs an IPC primitive (the pipe), and platform for building applications (the shell) and a standard data representation (line == record). It also needs a market - a reason for existence.
My own feeling of the market is for interactive tools. With pipe line, there is no opportunity for a conversation between elements of the pipeline. There is no way to have a "server" which will respond to requests, or a client that can give more information. So interactivity would be my choice of market place. Note that this doesn't mean interactive in a 'human-interacts-with-computer' sense, but in a 'client interacts with server' sense.
This is by no means a new market - there have been RPC (remote procedure call) systems for decades. There is even CORBA which is designed to make parts easily interchangeable. But somehow they don't seem to have the same degree of use as pipelines.
I also think that the IPC primitive is already available. I see two primitives as being usable. One is loadable modules, and the other is Unix domain sockets.
Loadable modules allow the server to run in the same address space as the client, which should provide high bandwidth and low latency. It does require the server to be single threaded and to only server one client at a time. For many applications this would be fine.
Unix domain sockets are an easy way to create a connection between two processes, much like a pipe. It is better than IP sockets as there is natural permission checking.
That just leaves a suitable data format, and a usable platform.
I think it would be a mistake to try to define how fields fit into records, what separator to use, and how to label fields. It might be worth doing this if we were trying to make pipelines better, but we are going beyond that.
I see that appropriate abstraction being a namespace line a filesystem. Each server presents a namespace. Each name can be "opened" and the resulting channel can be subject to "read" and "write". Each client sees it's own namespace, so that different clients don't affect each other unless that is the purpose of the service.
I have been following SPF for a while and have been thinking through the whole junk-mail control issue.
I have come to the conclusion that the only viable long-term solution is agressive whitelisting.
I have been having thoughts about setting up a local service to support whitelisting.
I often get the feeling that I am thrashing - lots of little things to do, plenty of interruptions, stuff gets done but it doesn't seem to get done as efficiently as it should. I spend to much time trying to decide what to do next.
So I recently (well, a few weeks ago now) realised that it was time for something to change.
Since then, I have been planning to do one thing each day. Sometime two if the second one was small, but normally one.
If I get an interruption that cannot be dealt with immediately, I schedule it in so that it has it's day, a few days hence.
This has been working REALLY WELL.
On the whole, I am very pleased.
I want to write a book - probably a silly idea.
The book would be about Design Patterns used in the Linux Kernel. Maybe call it
Linux Kernel Patterns
The target audience would be programmers who want to understand the Linux kernel and be able to develop code for it. It should cover Patterns in the human development process as well as patterns in the code.
It might be divided into parts:
Development patterns
External interface patterns
Internal interface patterns
Locking patterns
subsystem maintainers and mailing lists
development/stable cycle
developer-own trees.
If you make an incompatable interface change, make sure old users wont compile.
how to call userspace
ioctls
filehandles for everything (FUTEX)
Negative error numbers, in integers and pointers.
Switched interfaces / helper functions
operations structures with labels
cache update : test / allocate / test-and-insert
dec_and_lock
Make the common path fast, and the uncommon path just work.
Defensive: check all user input, rate limit warning, limit resources that can be consumed by the unprivileged.
It might be nice to make information and management available through sysfs. Maybe.