hi there,
Previously when I was hacking STREAMS coded we had a userspace
environment where on one machine we could have a few userspace
STREAMS processes, and a few userspace virtual network processes,
they all talked to each other with STREAMS drivers which could
talk with the virtual networks.
So on one machine you could have a complete simulated network, and
you could then run network programs on each of the virtual hosts.
This was cool, but now I don't have access to this. :-( So I'm
looking at LiS for development.
That would be a great test environment.
I've played with it for a few days now and would like to get some
confirmation about what I've discovered.
1) Can the kernel version of LiS only be debugged with GDB source
level debugger with a two machine setup?
There may be other ways, but I use the two-machine setup.
2) The userspace version does not have access to the TCPIP stack, so
it can only be used standalone? (and for 'loopback' or 'testharness'
cases)
Correct. Although you could write some special streams drivers that would write the messages into sockets. You'd probably need to wire in poll() to detect input on a socket and turn the recv() data into a STREAMS mblk.
3) For kernel version 'strtst' program talks to the kernel LiS. For the
userspace version, it looks like 'strtst' is both the 'userspace' program
and the STREAMS part, in one program. So the 'interface' between program
and STREAMS is just a function call? Maybe I missed something, but does
this not put limitations on the userspace version?
That's exactly it. streams.o + strtst.o + usrio.o make one monolithic program with a dinky little simulated file system. I never made it more general than that, but it would be a tremendously useful debugging tool for STREAMS drivers if someone could do it.
It may be possible to write some sort of bridge driver whose wput procedure would do a putmsg to a kernel driver coupled with poll() for input in which the getmsg turns into a call on the rput routine. Then you could have your device driver in the kernel and the rest of the protocol stack in user space running under gdb. That would be pretty sweet.
Basically, I'm looking to set up a development environment and would be
interested to know how you develop your STREAMS code?
Do you just take the hit of debugging the kernel, do you have a clever
userspace setup, or do you just write the code and it works first time!
Hey, I never thought of that! I'll try that next time :)
-- Dave
