Thomas Schwinge <[EMAIL PROTECTED]> writes: > Hello!
Hi! > 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. Cheers, Fredrik _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
