> On 09/17/10 09:34, goinsane wrote:
> > Yes, you're right, the manpage expresses this, too.
>
> > But how to get the value? copyin returns the
> address of the scratch buffer. could this be used as
> argument of the 2nd copyin of
> fbt:sockfs:accept:return ?
> >
> > fbt:sockfs:accept:entry
> > {
> > self->sockaddr = arg1;
> > self->socklen = (int*)copyin(arg2, 4);
> > }
>
> It's an in-out parameter. The value at entry is just
> the _maximum_ size
> of the caller's buffer, and not the _actual_ size of
> the returned data.
>
> > fbt:sockfs:accept:return
> > {
> > self->sockcont = (struct
> sockaddr_in*)copyin(self->sockaddr, self->socklen);
> > }
>
> I would do this in the entry clause:
>
> self->sockaddr = arg1;
> self->socklenp = arg2;
>
> and then this in the return clause:
>
> self->socklen = *(int *)copyin(self->socklenp, 4);
Oh, I forgot to derefence it. I should really refresh my knowledge of C ...
> self->sockcont = (struct sockaddr_in
> n *)copyin(self->sockaddr,
> self->socklen);
>
> (This assumes the application is 32-bit or at least
> that the system is
> little-endian. Things get more complicated if you
> have to deal with
> 64-bit big-endian systems.)
>
Hm, that's a point I had not noticed yet. I expected the D scripts running
independent from the system's arch. But as it becomes more complex, it seems
this has to be handled, too.
Right now, I'm running at 64 bit i86pc . I'm getting a value of the port (have
to verify it), but no value of the ip address.
self->port = self->sockcont->sin_port;
self->ip_int = (uint_t)self->sockcont->sin_addr.s_addr;
> To be really robust, you could have multiple return
> causes -- one to get
> the return length, another to check it and fetch the
> contents, still
> another to look at the sa_family, and so on.
That's the one I'll try next.
Tank you very much, James!
>
> --
> James Carlson 42.703N 71.076W
> <carls...@workingcode.com>
> _______________________________________
> dtrace-discuss mailing list
> dtrace-discuss@opensolaris.org
>
--
This message posted from opensolaris.org
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
