Skip to content
A scene from Ireland

Neil @ Home

Better read-ahead management and other file-open issues

NFS (prior to V4) does not have a concept of opening and closing a file. The Linux VFS does include that concept. So the NFS server has to open the file before a READ or WRITE operation, and close it afterwards.

Some funcitonality in filesystems and in the VFS assumes that the open/close requests that are passed down correspond to opens and closes by the application, and that a particular "file" structure belongs to a particular application (possibly a group of processes). Thus he current open/IO/close approach does not give good information to filesystems

Dynamic thread count

The number of nfsd threads is currently static, though it can be changed from user-space.

There is value is having a dynamic number of threads. It means that the system administrator does not need to pick a number and hope it works. Even if the sysadmin is very clever, there will often be either too many threads, wasting memory, or too few causing uneeded delays. Having a dynamic number of threads means that the number can follow load.

diff/patch editor

Another Use Case has occurred to me that I would really like this (hypothetical) editor to be able to support well. That is a diff/patch editor.

The basic idea is that when doing distributed software development, the items that are traded are patches. It is important to be able to work with these effecitively, both including them into ones own source tree, and generating a set of patches to distribute

Programming Approach

The point of this article is to try to describe the approach to developing an application within this editor.

A substantial motivation for this editor was the (apparent) difficulty in writing applications for EMACS. The difficulty lies in the need to worry about the wrong sort of detail. In EMACS that display is very tightly tied to the buffer contents. It is possible to hide parts of the buffer, and to display parts of the buffer differently, but the level of abstraction seems all wrong. There needs to be a clearer separation between the buffer and the display, with the option of arbitrary programatic conversion from buffer to display.

For this to be achievable without simply introducing a different sort of complexity there needs to be a clear model explaining how things should work.

More about documents

Many documents consist of just a single file, that can be read into a single document buffer. However this is not always the case.

A good example is a mailbox containing mail to be read. This can sometimes be a single file, but can also be a collection of files, either read from the filesystem or from a network connection such as with POP and IMAP. Another example is an HTML page that contains images. These images are stored in separate files.

Parsing Procedure

Parsing of documents needs to happen incrementally, both a high-level parse that just finds major sections, and low-level parses that only do a small local part of the document.

UNFINISHED