Porting gensio to an embedded system #7
Comments
|
On Wed, Jan 22, 2020 at 05:07:08AM -0800, matswebjorn wrote:
It turns out that the makesystem does not produce an executable. Instead it produces an extensive bash script which makes it very hard to understand
1) How to debug the code with a debugger
Well, libtool is kind of a pain, but it has reason to exist. It handles
shared libraries smoothly, which about nothing else does.
To run a program in the debugger or in valgrind, or something like that,
the format is:
<path>/libtool execute gdb .....
and libtool will do the right thing for you under a *nix system. <path>
is the patch to the top of the source code tree.
2) How to port the code to an embedded system as dependencies are unclear
It would really help if the build system was simplified so that it became clear what dependancies the package has to external sources. And so that code can be debugged.
Yeah, build systems are a pain. If you are using a *nix kind of system,
autoconf/automake/libtool is the standard way to do things, but it
doesn't port to non-unix-type systems very well.
What embedded system are you trying to port to? I wasn't expecting
anyone to really use it on anything else but perhaps Windows. It can be
done and it's not hard on a smallish thing like gensio, as long are you
are only generating .a files and static executables. If you want to
generate the makefiles for this, I could integrate them.
BTW, if you aren't using the head of the git tree, I have been doing
some significant work that is about to be released. There are no
interface changes, but I added an OOM tester which found a boatload of
bugs.
…-corey
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#7
|
|
On Sat, Jan 25, 2020 at 02:02:50PM -0800, James Hilliard wrote:
I added a gensio package to [buildroot](https://buildroot.org/) [here](buildroot/buildroot@6b8050e). It appears that gensio doesn't have any required dependencies other than a toolchain with `fork()` support.
I haven't done much work on anything except *nix systems. But fork()
support is only required for the stdio and pty gensios, which can be
easily excluded.
There is also the BSD-like network interfaces. But those are pretty
standard across all platforms. I think SCTP is autodetected along with
a few other things.
One think I need to do is make it easier to choose the gensios you want
to compile in to your program, more for embedded kind of stuff, which I
haven't thought much about.
…-corey
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#7 (comment)
|
Embedded build systems usually have a cross debug setup that can be used, for example with buildroot you can use the gdbserver setup for debugging remote processes running on a target board. |
|
I just changed i tool/Makefile.am And now I get a statically linked app which can be executed/debugged directly |
|
This is my POC design which once it is running should be ported to my ucLinux embedded target. I’ve taken gensiot.c and modified it (as I believe is how it should be done) to a gensiomux.c which only handles serialdev’s (to simplify the case). But I quickly end up inside gensio with runtime errors due which seems to be caused by an incorrect setup.
Gensiotool.c has on line 459 the following lines which seems to link upstream serialdev with downstream serialdev, but I don’t know if this is required in the mux case, and how to do it. |
|
On Sun, Jan 26, 2020 at 10:55:26PM -0800, matswebjorn wrote:
This is my POC design which once it is running should be ported to my ucLinux embedded target.
```
putty(1) putty(2) putty(3) putty(4)
| | | |
/dev/tnt2 /dev/tnt4 /dev/tnt6 /dev/tnt8
| | | |
/dev/tnt3 /dev/tnt5 /dev/tnt7 /dev/tnt9
| | | |
gensio-mux gensio-mux
| |
gensio-serialdev gensio-serialdev
| |
/dev/tnt0 /dev/tnt1
| |
+------- tty0tty ------+
```
I’ve taken gensiot.c and modified it (as I believe is how it should be done) to a gensiomux.c which only handles serialdev’s (to simplify the case).
But I quickly end up inside gensio with runtime errors due which seems to be caused by an incorrect setup.
- Am I totally wrong in setting up the mux?
Well, sort of. A mux will not run over an unreliable connection, and a
serialdev is not reliable. If you look at the top of
mux_gensio_alloc(), you will see:
if (!gensio_is_reliable(child))
/* Cowardly refusing to run MUX over an unreliable connection. */
return GE_NOTSUP;
The mux expects that no data will be dropped or mangled; if that happens
the mux is likely to get a protocol error and shut down.
And over a serial port, there is no real way to signal the other mux
that something has gone wrong. Well, I guess you could use modem control,
but that would take a little work that might be good to do. But it doesn't
solve the data drop/mangle problem.
The other problem you will run into is that one side of the mux expects
to be a server (the accepter side) and the other side expects to be a
client (the connecter side). In the configuration you have, both will
be clients, and it won't work. I need to add overrides like is already
in telnet, ssl, and certauth. That's easy to do.
My next project is to add a reliable transport over an unreliable
medium, which would be what you need. It would add overhead. I'm
actually primarily doing it so I can test udp more reliably (the really
nasty tests sometimes drop packets), but it would benefit you. Not sure
when that is going to happen, though.
You can remove that check, but things may go haywire if something goes
wrong on the serial port, and it won't be recoverable without
restarting both sides.
- Should there also be serialdev’s on each upstream port of the mux?
Yes, you would need something bridging the data from /dev/tnt[3579] into
the top of the mux. I'm not sure how you have that now.
-
[gensiomux.c.tar.gz](https://github.com/cminyard/gensio/files/4115851/gensiomux.c.tar.gz)
Gensiotool.c has on line 459 the following lines
```
userdata1.user_io = userdata1.io;
userdata2.user_io = userdata1.io;
```
which seems to link upstream serialdev with downstream serialdev, but I don’t know if this is required in the mux case, and how to do it.
No, this is only for error reporting. user_io is how error/log
information gets to the user.
…-corey
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#7 (comment)
|
Just to comment on this: everything is extensively documented in the man pages. That may not be how you are wanting to read it (and indeed, it's not my favorite way to document things) but that's standard on unix type systems. I really don't want to document things in multiple places; that's a recipe for inconsistency and confusion. If you build gensio on your host and install it (installing in /usr/local works fine for me, but I'm not sure about other distros) then you can do "man gensio_open" to see documentation on that function. The package is new, so it's going to have some rough edges. I covet any specific comments people have on improving it. Especially documentation. |
|
Note that gensios exist that can do reliable transport over a serial port, and you could run the mux on top of that. Anyway, I think this discussion is complete. |
It turns out that the makesystem does not produce an executable. Instead it produces an extensive bash script which makes it very hard to understand
It would really help if the build system was simplified so that it became clear what dependancies the package has to external sources. And so that code can be debugged.
Also, the complete lack of detailed documentation of functions and datastructures makes the package literally unusable to anything else than to use the predefined tools as is which is unfortunate since there is a great need for a usable package with this functionality.
The text was updated successfully, but these errors were encountered: