Re: client-side memory buffers

At Mon, 31 Mar 2008 21:23:41 -0600, Joshua Stratton wrote: > > I was on the irc channel talking about the feasibility using client-side > memory buffers for a new network stack. Based on some feedback about > difficulties of implementing this in the Hurd, I thought I would ask anyone > if they th

Re: [GSoC] GNU/Hurd Sound Support

On Tue, Apr 1, 2008 at 4:46 AM, <[EMAIL PROTECTED]> wrote: > Hi, > > > On Mon, Mar 31, 2008 at 10:22:11PM +0200, Mohammed Gamal wrote: > > > This is kind of a late follow up to these threads [1][2]. > > Well, why not just reply in that thread, then? :-) That would have made > it much easier to

Re: Hurdish TCP stack (was: updated proposal)

On Mon, Mar 31, 2008 at 02:07:26PM -0600, Joshua Stratton wrote: > If anyone hasn't read up on how Plan9 runs their network stack, they have a > separate directory of each connection. An example in the paper is shown as > the following, > > # cd /net/tcp/2 <--- this is like the second TCP conne

Re: hurd internet through qemu

Hello! Please don't top-post, see . Please keep discussions on public mailing lists, see . On Mon, Mar 31, 2008 at 03:27:28PM -0600, Joshua Stratton wrote: > On Mon, Mar 31, 2008 at 3:18 PM, Thomas Schw

Re: [GSoC] GNU/Hurd Sound Support

On Tue, Apr 01, 2008 at 10:59:09AM +0200, Mohammed Gamal wrote: > I have good experience with C/C++ and I am familiar with POSIX API, my > coding experience was generally in userspace, I didn't do anything > serious in kernel space. As for your suggestion, I think it's a very > good idea. Sound su

Re: Hurdish TCP stack

Hi, "Joshua Stratton" <[EMAIL PROTECTED]> writes: > They use an interesting system to control their connections using ASCII > strings. For example changing the packet size would be as simple as "2400 >> ctl" would change the packet size to 2400 (some syntax to that effect). Plan 9 does everyth

Re: [GSoC] GNU/Hurd Sound Support

On Tue, Apr 1, 2008 at 1:31 PM, Richard Braun <[EMAIL PROTECTED]> wrote: > On Tue, Apr 01, 2008 at 10:59:09AM +0200, Mohammed Gamal wrote: > > I have good experience with C/C++ and I am familiar with POSIX API, my > > coding experience was generally in userspace, I didn't do anything > > serious

Re: client-side memory buffers

On Tue, Apr 1, 2008 at 2:28 AM, Neal H. Walfield <[EMAIL PROTECTED]> wrote: > At Mon, 31 Mar 2008 21:23:41 -0600, > Joshua Stratton wrote: > > > > I was on the irc channel talking about the feasibility using client-side > > memory buffers for a new network stack. Based on some feedback about > >

Re: Hurdish TCP stack (was: updated proposal)

> > > > I think this approach would fit nicely into the Hurd's translator > > architecture. However, I'm not sure if I like the directory structure > they > > use. I would think the network interface should be shown like > > > > /net/eth0/tcp/2 > > > > It might be worthwhile--but possible bad sty

Re: [GSoC] GNU/Hurd Sound Support

On Tue, Apr 01, 2008 at 03:15:02PM +0200, Mohammed Gamal wrote: > I am familiar with the Linux kernel, although on a basic "big picture" > level, and I am also familiar with its device driver subsystem. > However the whole point of GSoC is to develop one's skills by getting > involved in the FOSS c

Re: Hurdish TCP stack (was: updated proposal)

On Tue, Apr 01, 2008 at 08:07:23AM -0600, Joshua Stratton wrote: > > It's clearly a mistake to map the directory tree to the protocols stack. > > The TCP implementation is a global layer, it handles network interfaces > > internally and must not be bound to any interface (ask yourself how to > > im

Re: client-side memory buffers

At Tue, 1 Apr 2008 08:11:30 -0600, Joshua Stratton wrote: > On Tue, Apr 1, 2008 at 2:28 AM, Neal H. Walfield <[EMAIL PROTECTED]> wrote: > > The problem is exactly the same as that with L4's data spaces. When > > the server maps and accesses the memory object, the client can revoke > > the mapping

Re: Hurdish TCP stack

El Tue, Apr 01, 2008 at 02:55:28PM +0200, Ludovic Courtès ens deleit� amb les seg�ents paraules: > Hi, > > "Joshua Stratton" <[EMAIL PROTECTED]> writes: > >> They use an interesting system to control their connections using ASCII >> strings. For example changing the packet size would be as sim

Re: client-side memory buffers

The problem you described was the client owning the memory object, sending it to the server, and the server having the ability to unmap the memory because it has ownership, if I understand correctly. I assumed that a lock was built into the system to prevent this, but I was wondering if this weren

Re: Hurdish TCP stack (was: updated proposal)

Okay, I understand. I think part of this goes back to a question on the reason for enumeration on these sockets (tcp0, tcp1, etc.) if they aren't used directly in the socket interface for the developer. I assumed it was as a convenience for other programs that were monitoring the network. I agre

Re: Hurdish TCP stack

Hi, On Tue, Apr 01, 2008 at 12:45:13PM +0200, Richard Braun wrote: > In addition, separating the network and transport layers implies > several problems. The most obvious one concerns performance. The Mach > IPC subsystem provides nice virtual copy support, but this facility > creates an importan

Re: [GSoC] GNU/Hurd Sound Support

Hi, On Tue, Apr 01, 2008 at 03:15:59PM +0200, Mohammed Gamal wrote: > I am familiar with the Linux kernel, although on a basic "big picture" > level, and I am also familiar with its device driver subsystem. > However the whole point of GSoC is to develop one's skills by getting > involved in the

Re: [GSoC] GNU/Hurd Sound Support

Hi, On Tue, Apr 01, 2008 at 01:31:37PM +0200, Richard Braun wrote: > With more experience, I'd suggest you don't use my code. The "bug" I > had was mainly due to my misuse of the Mach VM and IPC interfaces, and > I currently don't have enough time for hacking on this again :'(. It would already

Re: [GSoC] GNU/Hurd Sound Support

Hi, On Tue, Apr 01, 2008 at 10:59:09AM +0200, Mohammed Gamal wrote: > However, does what you say here mean that we'd rather have to write > the drivers directly in the Mach kernel? Yes. As I said, userspace drivers would be desirable, but not realistic. -antrik-

Re: [GSoC] GNU/Hurd Sound Support

Hi, On Tue, Apr 01, 2008 at 05:04:41PM +0200, Richard Braun wrote: > On Tue, Apr 01, 2008 at 03:15:02PM +0200, Mohammed Gamal wrote: > > I am familiar with the Linux kernel, although on a basic "big > > picture" level, and I am also familiar with its device driver > > subsystem. However the whole

Re: Hurdish TCP stack

Hi, On Tue, Apr 01, 2008 at 05:20:54PM +0200, Richard Braun wrote: > /dev/net/tcp/123 is OK. /dev/eth0/tcp/321 isn't. As I said, you must > consider TCP as a global layer, otherwise you will run into name space > conflict problems. For example, a socket in listen mode on INADDR_ANY > is bound to

Re: Hurdish TCP stack

Hi, On Tue, Apr 01, 2008 at 02:55:28PM +0200, Ludovic Courtès wrote: > "Joshua Stratton" <[EMAIL PROTECTED]> writes: > Plan 9 does everything through "ctl" files that can be read and > written to with `cat' and `echo', pretty much like Linux sysfs. The > downside is that all commands have to be

Re: Hurdish TCP stack

Hi, On Mon, Mar 31, 2008 at 09:43:25PM -0600, Joshua Stratton wrote: > LP is a special protocol written by the Plan9 team that is something > in between TCP and UPD. They wanted a reliable stream but as fast as > UDP and a few other benefits. They said TCP was too slow. Interesting. I wonder

Re: client-side memory buffers

Scribit Joshua Stratton dies 01/04/2008 hora 10:48: > The problem you described was the client owning the memory object, > sending it to the server, and the server having the ability to unmap > the memory because it has ownership, if I understand correctly. The problem is that the *client* can unm

Re: client-side memory buffers

On Tue, Apr 1, 2008 at 12:32 PM, Pierre THIERRY < [EMAIL PROTECTED]> wrote: > Scribit Joshua Stratton dies 01/04/2008 hora 10:48: > > The problem you described was the client owning the memory object, > > sending it to the server, and the server having the ability to unmap > > the memory because i

Re: client-side memory buffers

On Tue, Apr 1, 2008 at 3:50 PM, Neal H. Walfield <[EMAIL PROTECTED]> wrote: > Please don't top post. > > At Tue, 1 Apr 2008 10:48:02 -0600, > Joshua Stratton wrote: > > > > The problem you described was the client owning the memory object, > sending > > it to the server, and the server having the

Re: client-side memory buffers

Please don't top post. At Tue, 1 Apr 2008 10:48:02 -0600, Joshua Stratton wrote: > > The problem you described was the client owning the memory object, sending > it to the server, and the server having the ability to unmap the memory > because it has ownership, if I understand correctly. No. Th

Re: client-side memory buffers

Hi, On Tue, Apr 01, 2008 at 10:48:02AM -0600, Joshua Stratton wrote: > The problem you described was the client owning the memory object, > sending it to the server, and the server having the ability to unmap > the memory because it has ownership, if I understand correctly. The problem is that t

Re: client-side memory buffers

At Tue, 1 Apr 2008 18:01:25 -0600, Joshua Stratton wrote: > On Tue, Apr 1, 2008 at 3:50 PM, Neal H. Walfield <[EMAIL PROTECTED]> wrote: > > > Please don't top post. > > > > At Tue, 1 Apr 2008 10:48:02 -0600, > > Joshua Stratton wrote: > > > > > > The problem you described was the client owning the

GSoC project about virtualization using Hurd mechanisms

Hello, I want to do the project of virtualization using Hurd mechanisms. There are two choices for me: to improve subhurds and to create a new subenvironments. Here are the descriptions about them: In my understanding, Hurd is a set of servers which provide the services provided by the monolit