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
