[Top][All Lists]

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

Re: GSoC project libchannel

From: Carl Fredrik Hammar
Subject: Re: GSoC project libchannel
Date: Thu, 14 Jun 2007 16:47:14 +0200
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/22.0.990 (gnu/linux)

Thomas Schwinge <tschwinge@gnu.org> writes:

> Hello!


> Downward from the heights where the tower is installed in which the Hurd
> administration resides ;-) I'm asking the question: what is the state of
> this year's GSoC project, libchannel?  Fredrik, how are you coming along?

Well to be honest I haven't been able to get started properly until a
few days ago, due to various reasons mostly school and a persistant
ear infection.  But the good news is that all of that is out of the
way now. :-)

Right now I'm going over libstore's implementation checking what can
be reused and writing up a specification for libchannel.  The question
is how to put it up for review.  I could just send it in a series of
mails to the list.  But I figure I might as well just write the
documentation first and use that as a spec or possibly the header
files.  What do you guys think?

I'll also take this opportunity to see if some assumptions I have made
are correct:

Channels aren't seekable.  This seems obvious, but I wrote a small
program that test if a file is seekable by trying to seek to the end
of a file and while character devices (such as /dev/zero) wasn't
seekable in the Hurd but it was in my GNU/Linux system.  I haven't
investigated furthur but I'm guessing that linux either ignores seeks
or supplies only rudamentary support for it by simply skipping bytes.
The question is which semantics are the propper one?

Channels aren't mmappable.  I haven't done any tests for this one.
But like seekability this can also be faked by simply filling
anonymous memory with the channels contents.

Implementing these would keep some programs from breaking, but I'm
guessing these are few.  Defining precise semantics would also be hard
(what to do when seeking backwards, writing back mmapped pages, etc).
So I'm thinking it would be best to leave them unimplemented.


reply via email to

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