Can some kind soul provide a code snippet of what should be done
in the io_readlink handler? I’ve gotten the ramdisk to the point
where it correctly differentiates the S_ISLINK on the io_open, and
either allows the open “as is” (if S_ISLINK (msg → connect.mode)
is true) or (currently) fails.
When it allows the open “as is”, I then get called in my io_readlink
handler, but looking at iomsg.h at the _io_connect_link_reply there
are a whack of fields and I’m not quite sure how to fill them in…
Rest assured that this will be documented in the book so as to avoid
this question in the future 
Thanks very much in advance!
-RK
–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.
Robert Krten wrote:
Can some kind soul provide a code snippet of what should be done
in the io_readlink handler? I’ve gotten the ramdisk to the point
where it correctly differentiates the S_ISLINK on the io_open, and
either allows the open “as is” (if S_ISLINK (msg → connect.mode)
is true) or (currently) fails.
When it allows the open “as is”, I then get called in my io_readlink
handler, but looking at iomsg.h at the _io_connect_link_reply there
are a whack of fields and I’m not quite sure how to fill them in…
Rest assured that this will be documented in the book so as to avoid
this question in the future >
Thanks very much in advance!
Here’s the relevant snippet of code from my resmgr (written
in C++). Basically after finding the node in question,
(Node->Data() contains the path for the link) you stuff
it into a _io_connect_link_reply (pretty much the same
as returning a symlink).
struct _io_connect_link_reply reply;
Link &link=FindLink(msg->connect.path);
memset(&reply, ‘\0’, sizeof reply);
SETIOV(&ctp->iov[0], &reply, sizeof(reply));
SETIOV(&ctp->iov[1], link.m_Node->Data(),
strlen((char *)link.m_Node->Data())+1);
return _RESMGR_NPARTS(2);
Robert Krten wrote:
Thanks Rennie…
I had kinda figured out the first part, of stuffing the data after
the header (just yesterday), but was left with the question of
what to put in the hearder. You just seem to jam in zeros.
That’s what I’m doing, and it seems to work >
Yeah (shrug) if in doubt, stuff zeros
Rennie Allen <rgallen@attbi.com> wrote:
Robert Krten wrote:
Can some kind soul provide a code snippet of what should be done
in the io_readlink handler? I’ve gotten the ramdisk to the point
where it correctly differentiates the S_ISLINK on the io_open, and
either allows the open “as is” (if S_ISLINK (msg → connect.mode)
is true) or (currently) fails.
When it allows the open “as is”, I then get called in my io_readlink
handler, but looking at iomsg.h at the _io_connect_link_reply there
are a whack of fields and I’m not quite sure how to fill them in…
Rest assured that this will be documented in the book so as to avoid
this question in the future >
Thanks very much in advance!
Here’s the relevant snippet of code from my resmgr (written
in C++). Basically after finding the node in question,
(Node->Data() contains the path for the link) you stuff
it into a _io_connect_link_reply (pretty much the same
as returning a symlink).
struct _io_connect_link_reply reply;
Link &link=FindLink(msg->connect.path);
memset(&reply, ‘\0’, sizeof reply);
SETIOV(&ctp->iov[0], &reply, sizeof(reply));
SETIOV(&ctp->iov[1], link.m_Node->Data(),
strlen((char *)link.m_Node->Data())+1);
return _RESMGR_NPARTS(2);
Thanks Rennie…
I had kinda figured out the first part, of stuffing the data after
the header (just yesterday), but was left with the question of
what to put in the hearder. You just seem to jam in zeros.
That’s what I’m doing, and it seems to work
Thanks,
-RK
–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.
Rennie Allen <rallen@csical.com> wrote:
Robert Krten wrote:
I had kinda figured out the first part, of stuffing the data after
the header (just yesterday), but was left with the question of
what to put in the hearder. You just seem to jam in zeros.
That’s what I’m doing, and it seems to work >
Yeah (shrug) if in doubt, stuff zeros >
Actually you should set ‘path_len’ to the length of the link name
(not counting a trailing ‘\0’) and copy the ‘eflag’ over from the
original readlink message …
John Garvey wrote:
Rennie Allen <> rallen@csical.com> > wrote:
Robert Krten wrote:
I had kinda figured out the first part, of stuffing the data after
the header (just yesterday), but was left with the question of
what to put in the hearder. You just seem to jam in zeros.
That’s what I’m doing, and it seems to work >
Yeah (shrug) if in doubt, stuff zeros >
Actually you should set ‘path_len’ to the length of the link name
(not counting a trailing ‘\0’) and copy the ‘eflag’ over from the
original readlink message …
Cool. No more doubt. Thanks.
