Re: client-side memory buffers

2008-04-03 Thread Joshua Stratton
> > > Do you think the client-side > > memory model is worthwhile? And would the server allocating the memory > > passing it to the client using the Mach semantics allow this client-side > > memory model while avoiding the ability for clients to unmap the > > data? > > Yes, I think such accounting

Re: Hurdish TCP stack

2008-04-03 Thread Ludovic Courtès
Hi, <[EMAIL PROTECTED]> writes: > Actually, most people will consider it easier to use it from a C program > as well: For one, it means that you can use the *same* knowledge for > doing stuff on the shell, and for writing C programs. That's a very > valuable property IMHO. Isn't it easier to wri

Re: Hurdish TCP stack

2008-04-03 Thread Ludovic Courtès
Lluis <[EMAIL PROTECTED]> writes: > But as I understand it, rpctrace can only look at ongoing messages Yes, I was only referring to `rpctrace' because of its ability to map raw message IDs to RPC signatures, which seemed useful in building lightweight introspection facilities. Thanks, Ludovic.

Re: Hurdish TCP stack

2008-04-03 Thread Lluis
El Thu, Apr 03, 2008 at 05:16:24PM +0200, Ludovic Courtès ens deleit� amb les seg�ents paraules: >> Well, I don't know how rpctrace internally works, but I suppose it's >> someting similar to ptrace, which gives information at "use-time", while >> such a filesystem would need some kind of intros

Re: Hurdish TCP stack

2008-04-03 Thread olafBuddenhagen
Hi, On Wed, Apr 02, 2008 at 09:23:20AM +0200, Ludovic Courtès wrote: > <[EMAIL PROTECTED]> writes: > > A filesystem based interface is much easier to use for most > > programmers than generic RPCs. > > It's easier to use from a shell, not from a C program. Actually, most people will consider it

Re: Hurdish TCP stack

2008-04-03 Thread Ludovic Courtès
Hi, Lluis <[EMAIL PROTECTED]> writes: > Well, I don't know how rpctrace internally works, but I suppose it's > someting similar to ptrace, which gives information at "use-time", while > such a filesystem would need some kind of introspection mechanism on the > destination servers, in order to

Re: Hurdish TCP stack

2008-04-03 Thread Lluis
El Wed, Apr 02, 2008 at 09:19:12AM +0200, Ludovic Courtès ens deleit� amb les seg�ents paraules: > Hi, > > Lluis <[EMAIL PROTECTED]> writes: > >> I'm just an sneaker in many lists but... does Hurd support introspection? >> Or has any plan to support it? In that case there could be an introspec