[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Questions about translators

From: Ciaran O'Riordan
Subject: Re: Questions about translators
Date: Mon, 24 Mar 2003 04:52:30 +0000
User-agent: Mutt/1.4i

On Sun, Mar 23, 2003 at 11:03:32PM -0500, Hiran Watson wrote:
> Thanks first off!

no problem.

> First, I'm confused then about the meaning of the following from the white 
> paper "Towards a New Strategy of OS Design"

The wording is poor in places, I think it confused me too when I
started with the Hurd.  This is one of the more complex aspects
of the Hurd, two paragraphs is pretty terse.

Two situations are being explained.  The first case deals
with the simple operation of openning a regular file.

Your application wants to access a file on an ext2fs filesystem:
The ext2fs server is sent a request, the server opens the file.

In the second situation the file to be accessed has a note attached
to it saying that it needs special help to be useful.  There are
plans to write a 'gzip' translator so that files can be
automatically gzipped and gunzipped when they are closed/opened.
To make use of this translator, you would "associate" the gzip
translator with that file so that whenever the ext2fs translator
is asked to open this file it will see that it was to open it
through the gzip translator.

The translators get chained, or and extra layer is added to
the file access.

An appplication sends a "open" request to the ext2fs server.
The ext2fs server sees a 'gzip' note on the file.
The ext2fs server sends a "open" request to the gzip server.

The port-rights are then passed back along the chain.

This is good for illustrating the status of userspace
apps and servers.  In the above example the application
and ext2fs server make requests of other servers, each
has equal status, they are just two programs communicating.
What makes GNU Hurd servers special is that they agree on
a way to communicated.

Translators are associated with files via the 'settrans'
command, I think you pass it the '-p' switch (passive),
and the file and the translator.  This gets stored
in the filesystem in some spare space that is part
of the ext2 format.  Linux ignores data in this
spare space.

("translator" and "server" are always switchable, it
 just depends on the context as to which is clearer)

(I'll mail you tomorrow about the second question)

Good night.
Ciaran O'Riordan

> "Most servers are accessed by opening files.  Normally, when you open a 
> file, you create a port associated with that file that is owned by the 
> server that owns the directory containing the file. For example, a 
> disk-based filesystem will normally serve a large number of ports, each of 
> which represents an open file or directory. When a file is opened, the 
> server creates a new port, associates it with the file, and returns the 
> port to the calling program.
> However, a file can have a translator associated with it. In this case, 
> rather than return its own port which refers to the contents of the file, 
> the server executes a translator program associated with that file. This 
> translator is given a port to the actual contents of the file, and is then 
> asked to return a port to the original user to complete the open operation."
> I understand the first paragraph. But then the second one gives the 
> impression that the translator is started as another layer between the 
> end-user app and the server. Is it that the server just starts another 
> server? Or are they talking about server threads? So the main server thread 
> spawns a subthread that connects with the main thread through the port 
> decided by the server (main thread) and on the other end connects with the 
> end-user app through another port?
> Secondly, what happens when an end-user app makes a system call (ie, open 
> some file, or read, or write, etc.)? Does the call get caught by the kernel 
> which passes it onto the appropriate server? If so, then the layers would 
> be end-user apps on top; they're connected to the kernel; and the kernel is 
> connected to the servers; and finally the servers are connected to physical 
> hardware? If so, what about servers that don't actually mess with hardware?
> Thanks again.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]