Cherrypick from master 2000-05-24 16:51:23 UTC Joel Sherrill <joel.sherrill@OARcorp.com> 'New file.':
c/src/tests/libtests/malloctest/malloctest.scn
scripts/config.guess
scripts/config.sub
Comments follow:
This support is (for now) only available for the __i386 target, because
that's the only testing platform I have. It should to my best knowledge
work in the same way for the "__PPC" target, but someone should test
this first before it's put into the code. Thanks go to Andrew Klossner
who provided the vital information about the Intel 21143 chip.
(FWIW: my network card is a Kingston KNE100TX with 21143PD chip)
- CONFIGURE_RTEMS_INIT_TASKS_TABLE was 10 now 0
- CONFIGURE_POSIX_INIT_THREAD_TABLE was 10 now 0
- CONFIGURE_ITRON_INIT_TASK_TABLE was 10 now 0
- CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS was 20 now 3
- added CONFIGURE_NUMBER_OF_TERMIOS_PORTS and defaulted to 1
- added CONFIGURE_TERMIOS_DISABLED defaulted to "enabled"
- miniIMFS is now the default
Added configuration error checks that:
+ Ensure > 0 tasks/threads are configured
+ Ensure at least one inititalization task/thread is defined
bsp.h now defines so BSP specific requirements are accounted for:
+ CONFIGURE_NUMBER_OF_TERMIOS_PORTS
+ CONFIGURE_INTERRUPT_STACK_MEMORY
console_reserve_resources and rtems_termios_reserve_resources
are no longer required and considered obsolete. Calls to
rtems_termios_reserve_resources have been eliminated although
the routine is still there and the body "if 0'ed".
We are very close to having NO reason to modify the
configuration tables in the BSP. Be warned that eventually
we would like to see the need for BSP_Configuration
eliminated!
eliminate code which assumes that 4 * sizeof(unsigned32) == 16)
and that a 16 byte message can be assumed to be 4 unsigned32's.
These assumptions are invalid on target processors that are
not byte-addressable.
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.
