Alexey S. Fadeyev <alexey@vocord.com>. Discussion follows:
"Alexey S. Fadeyev" wrote:
> So if I run this application it tell me :
> > connect_task: Connection established
> > accept somthing
>
> But if I try to connect to invalid port (3001 for example) it also tell me
> that connection
> established but bind_task did't accept it. So how I can find out in
> connect_task does my connection realy
> exist ? What type of socket is here? Blocking or non-blocking? I try used
> select but it did't help - it
> always tell me from connect_task that connection is valid.
>
Yep -- there was a problem alright. The connect() routine wasn't
returning an error indication when it should have. Note that this
problem was not limited to the loopback driver -- a refused connection
from any server would return `success'.
includes RTEMS wrappers invoked by gcc. The beauty of this
is that it puts the implementation in our hands. :)
It uses a mutex ( semaphore ), and task variables simulating
the "keys" for each task.
Thanks to Rosimildo da Silva <rdasilva@connectel.com> for
submitting this.
Cherrypick from master 2000-05-08 20:36:59 UTC Joel Sherrill <joel.sherrill@OARcorp.com> 'New file added on 4.5 branch':
c/src/lib/libbsp/m68k/mvme167/console/console-recording.c
to address problems triggered when switching modes. His ChangeLog:
* c/src/lib/libbsp/m68k/mvme167/console/console-recording:
New file. Console debug info recording functions.
* c/src/lib/libbsp/m68k/mvme167/console/console.c:
Try to eliminate garbled characters when the line characteristics are
changed. Added debug info logging calls
* c/src/tests/libtests/termios/init.c: Remove sleep calls.
His longer description :)
This one was hard. I tried a number of approaches, and eventually came
to the conclusion that one cannot tell when the output FIFO have drained
completely. Consequently, the driver now includes delay loops that get
executed when the line discipline is changed. Yuk. I had a look at the
Linux and FreeBSD drivers; the FreeBSD driver uses delay loops while the
Linux driver contain warnings about characters getting garbled when the
line discipline is changed.
The new driver only re-initializes the cd2401 if some registers need to
change, otherwise, the chip is left alone. This is equivalent to caching
the previous setting and only changing things if they need to be. The
code is kind of ugly, but what can you do. The delay loops are only used
if the chip must be re-initialized.
Optional instrumentation that records what the driver is doing is
provided. It should be obvious how to enable it and how to use it. It's
not the best, but it got the job done.
I ran the termios test. The delay loops I had introduced are no longer
necessary, so I took them out. The patch includes that change. The test
re-initializes the chip whenever the canonical input test (test 4) is
run THE FIRST TIME OR AFTER THE LINE WAS RESET (test 1). The test did
not garble any characters when the chip was re-initialized (or when it
was not) while running at 9600 bsp. I therefore think that I have a
solution.
Cherrypick from master 2000-05-03 13:55:42 UTC Joel Sherrill <joel.sherrill@OARcorp.com> 'Added on 4.5 branch.':
c/src/librpc/src/rpc/rtems_portmapper.c
c/src/librpc/src/rpc/rtems_rpc.c
